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and  the  event  threads  both  within  and  external  to  the  staff  modules  thereby 
fixing  the  event  sequence  and  time  of  occurrence;  and  incorporating  into 
the  simulation  every  event  thread  needed  to  support  the  input/output  rela¬ 
tionship.  The  dynamic  realism  needed  to  place  decisionmakers  in  a  real¬ 
istic  environment  is  achieved  by  means  of  an  event  store  technique.  The 
five  classes  of  events  of  which  the  event  threads  are  composed  are  defined 
and  the  logical  flow  of  the  event  store  simulation  is  illustrated.  A  sixth 
class  of  event  needed  for  operation  in  an  ADP-assisted  mode  is  also  defined 
The  approach  begins  at  the  heart  of  the  information  system,  the  decisions, 
and  then  develops  the  simulation  needed  to  implement  them — the  inverse  of 
the  usual  approach. 

The  design  concept  provides  for  a  man  in  the  loop  in  that  any  one  or 
any  combination  of  five  basic  staff  modules  (Cmd  Grp,  G-2,  G-3,  G-l/G-4, 
FSCE)  plus  one  enemy  module  (Cmd  Grp)  may  be  either  occupied  by  human 
players  or  simulated.  The  module  simulations  are  designed  as  "plug-in" 
modules  any  one  or  more  of  which  can  be  replaced  by  players.  The  simula¬ 
tion  also  contains  a  battle  outcome  generator  which  simulates  all  other 
events  within  the  division  and  the  enemy  force  opposing  it,  and  which  feeds 
back  to  the  players  in  slow,  real,  or  fast  time  (at  the  option  of  the 
user)  the  results  of  their  decisions.  The  design  also  >rovides  for  inter¬ 
faces  with  higher  and  adjacent  units.  It  includes  the  following  features: 

1.  The  modules  are  based  on  the  traditional  G-staff  structure. 

2.  Nuclear  battle  events  are  included. 

3.  Live  modules  may  be  required  to  perform  simultaneous  planning 
and  execution;  the  results  of  such  planning  may  be  evaluated 
by  subsequent  execution  of  plans. 

4.  Other  staff  elements  not  included  in  the  basic  five  modules 
(e.g.,  engineer,  signal)  are  "hardwired"  components  of  the 
simulation. 

5.  The  basic  design  provides  for  manual  operation  by  live  players 
but  it  is  readily  expandable  to  permit  player  operation  in  an 
ADP-assisted  mode. 
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FOREWORD 


The  Army  Research  Institute  for  the  Behavioral  and  Social  Sciences 
(ARI)  conducts  research  on  tactical  information  systems  with  particular 
emphasis  on  the  human  factor  in  battlefield  command/control  and  intelli¬ 
gence  functions  and  operations.  The  development  and  refinement  of 
man-in-the-loop  simulations  to  serve  as  research  test-beds  is  a  necessary 
step  in  the  development  of  command  staff  aids  and  procedures  to  meet  the 
challenge  of  the  modem  battlefield.  The  ARI  research  program  in  this 
domain  is  independently  and  jointly  executed  by  the  Human  Factors  Technical 
Area  in  Alexandria,  Va. ,  and  the  ARI  Field  Unit  at  Fort  Leavenworth, 

Kans . 


The  present  report  describes  a  range  of  design  alternatives  for  a 
man-in-the-loop  simulation  for  research,  development,  and  training.  The 
basic  concept  developed  is  one  of  a  modular  simulation  where  one  or  more 
elements  within  the  command  staff  group  may  be  exercised,  with  controllers 
supervising  play  and  feeding  in  data,  etc. ,  from  unpopulated  (simulated) 
staff  elements.  Pre-established  event  threads  provide  a  means  for 
realistic  play  of  a  complex  scenario  with  a  relatively  small  controller 
team.  The  possible  role  of  computer  support  to  the  controllers  is  also 
discussed.  Detailed  design  specifications  are  provided  in  ARI  Technical 
Report  421.  This  effort  provides  part  of  the  methodological  and  tech¬ 
nological  base  required  for  development  and  evaluation  of  command  group 
aids  and  procedures. 

Research  on  staff  operations  and  procedures  is  conducted  both 
in-house  and  augmented  contractually  with  organizations  selected  for 
their  specialized  capabilities  and  unique  facilities.  Efforts  in  this 
area  are  responsive  to  general  requirements  of  Army  Projects  2Q162722A765 
and  2Q163743A774  and  to  special  requirements  of  the  U.S.  Army  Combined 
Arms  Combat  Development  Activity,  Fort  Leavenworth,  Kans.,  and  the  U.S. 
Army  Intelligence  Center  and  School,  Fort  Huachuca,  Ariz.  This  effort 
is  also  responsive  to  Human  Resource  Need  78-85  "War  Gaming  of  Intelli¬ 
gence,"  and  was  conducted  under  Contract  DAIiC19-77-C-0047  by  Science 
Applications,  Inc.,  monitored  by  both  the  Human  Factors  Technical  Area 
and  the  Fort  Leavenworth  Field  Unit  of  ARI. 
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DESIGN  OF  AN  INTEGRATED  DIVISION-LEVEL  BATTLE  SIMULATION  FOR  RESEARCH, 
DEVELOPMENT,  AND  TRAINING 

BRIEF 


This  volume  describes  the  structural  framework  of  the  simulation  and 
the  considerations  that  entered  into  its  design.*  A  companion  volume, 
DETAILED  DESIGN  NOTES  FOR  DESIGN  OF  AN  INTEGRATE!)  DIVISION-LEVEL  BAT¬ 
TLE  SIMULATION  FOR  RESEARCH,  DEVELOPMENT,  AND  TRAINING,  provides  more 
detailed  design  information.  s' 

^Requi  remen ~  - - -  ' 

1.  ^^evelop  a  top-down  design  for  an  integrated  family  of 
modular  division-level  battle  simulations  which  separately  or  jointly 
will  exercise  players  performing  critical  functions  in  command  and 
control 

2. )  Develop  detailed  design  specifications  for  the  Intelli¬ 

gence module  of  the  integrated  battle  simulation. 

S>The  design  approach  involved  the  following  principles:  selection  of 
the  decision  variables  to  be  manipulated  by  the  division  staff  modules 
and  the  event  threads  both  within  and  external  to  the  staff  modules 
thereby  fixing  the  event  sequence  and  time  of  occurrence;  and  incorpo¬ 
rating  into  the  simulation  every  event  thread  needed  to  support  the 
input/output  relationship.  The  dynamic  realism  needed  to  place  de¬ 
cision  makers  in  a  realistic  environment  is  achieved  by  means  of  an 
event  store  technique.  The  five  classes  of  events  of  which  the  event 
threads  are  composed  are  defined  and  the  logical  flow  of  the  event 
store  simulation  is  illustrated.  A  sixth  class  of  event  needed  for 
operation  in  an  ADP-assisted  mode  is  also  defined.  The  approach  be¬ 
gins  at  the  heart  of  the  information  system,  the  decisions,  and  then 
develops  the  simulation  needed  to  implement  them--the  inverse  of  the 
usual  approach.  '\ 


"^The  design  concept  provides  for  a  man  in  the  loop  in  that  any  one  or 
any  combination  of  five  basic  staff  modules  (Cmd  Grp,  G-2,  G-3, 
G-l/G-4,  FSCE)  plus  one  enemy  module  (Cmd  Grp)  may  be  either  occupied 
by  human  players  or  simulated.  The  module  simulations  are  designed 
as  "plug-in"  modules  any  one  oKmore  of  which  can  be  replaced  by 
players.  The  simulation  also  coktains  a  battle  outcome  generator 
which  simulates  all  other  events  wvthin  the  division  and  the  enemy 
force  opposing  it,  and  which  feeds  Dick  to  the  players  in  slow,  real, 
or  fast  time  (at  the  option  of  the  user)  the  results  of  their  de¬ 
cisions.  The  design  also  provides  for  the  interfaces  with  higher 
and  adjacent  units.  It  includes  the  following  features: 
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1.  The  modules  are  based  on  the  traditional  G-staff  struc¬ 
ture. 

2.  Nuclear  battle  events  are  included. 

3.  Live  modules  may  be  required  to  perform  simultaneous 
planning  and  execution;  the  results  of  such  planning 
may  be  evaluated  by  subsequent  execution  of  plans. 

4.  Other  staff  elements  not  included  in  the  basic  five 
modules  (e.g.,  engineer,  signal)  are  "hardwired" 
components  of  the  simulation. 

5.  The  basic  design  provides  for  manual  operation  by  live 
players  but  it  is  readily  expandable  to  permit  player 
operation  in  an  ADP-assisted  mode. 


Conclusions: 

The  general  top-down  design  of  the  simulation  has  been  de¬ 
veloped  as  has  the  more  detailed  design  of  the  Intelligence  Staff 
module.  However,  two  basic  design  problems  were  uncovered  in  the 
course  of  the  research. 

1.  A  fundamental  problem  is  inherent  in  the  modular  nature 
of  the  simulation.  If  a  populated  module  performs  below  standard 
(makes  errors,  omits  or  takes  illogical  actions)  how  can  simulated 
command  and  control  processes  reflect  the  degraded  force  effective¬ 
ness  that  results?  Although  much  simpler  to  implement,  standard  per¬ 
formance  by  simulated  command  control  nodes  independent  of  performance 
of  populated  modules  would  not  meet  simulation  objectives. 

2.  In  the  interest  of  economy  of  operation  and  player 
motivation  it  would  be  desirable  to  eliminate  or  reduce  the  require¬ 
ment  for  repetitive,  low-skill  tasks,  e.g.,  answering  radios  and 
telephones  and  transmitting  messages,  routine  filing,  etc.,  which 
have  little  impact  on  the  quality  of  decision  making  and  are  of  little 
interest  to  the  investigator.  It  may  also  be  desirable  to  modify  or 
recombine  tasks  in  investigations  of  alternative  procedures.  This 
can  be  difficult  to  accommodate  and  still  retain  a  credible,  realistic 
decision-making  environment. 

It  is  concluded  that  both  the  above  problems  are  serious  enough  to 
warrant  additional  analysis  before  implementing  the  simulation. 
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Section  1 


INTRODUCTION 


1.1  PURPOSE  AND  SCOPE 

This  report  describes  the  top-down  design  of  an  Integrated 
Division-Level  Battle  Simulation  for  Research,  Development,  and 
Training.  It  discusses  and  documents  the  critical  trade-offs  which 
need  to  be  made  in  further  development  and  implementation  of  the 
simulation  and  which  underlay  the  numerous  design  decisions  that 
have  already  been  made.  It  discusses  the  applicability  of  the  de¬ 
sign  to  the  three  major  areas  for  which  such  a  simulation  should  be 
useful,  namely: 

•  Behavioral  science  research  on  human  performance  in 
command  and  control. 

•  Combat  developments,  for  the  analysis  and  evaluation  of 
tactics  and  doctrine. 

•  As  a  training  device  for  command  groups/staff. 

Also  discussed  are  the  player  tasks  and  roles  in  each  of  the  modules, 
the  general  rules  of  play,  the  information  flow  required  to  support 
stand-alone  and  integrated  play,  controller  requirements  and  functions, 
data  to  be  obtained  and  evaluation  criteria  to  be  applied,  and  other 

aspects  of  the  design  necessary  to  allow  for  implementation  of  the 

simulation. 

1.2  APPROACH 

The  approach  to  the  design  of  this  simulation  is  somewhat  unique 
as  compared  to  past  designs  of  combat  simulations.  It  involves  the  ap¬ 
plication  of  the  following  principles: 

•  Selection  of  the  decision  variables  to  be  manipulated 
by  the  division  staff  modules  and  the  associated  inputs 
and  outputs. 

•  Tying  together  the  inputs  and  outputs  by  means  of  event 
threats  both  within  and  external  to  the  staff  modules 
thereby  fixing  the  event  sequence  and  time  of  occurrence. 

•  Incorporating  into  the  simulation  every  event  thread 
needed  to  support  the  input/output  relationship. 

This  approach  begins  at  the  heart  of  the  information  system,  i.e., 
the  decisions  to  be  made,  and  then  develops  the  combat  simulation 
needed  to  implement  them,  which  is  the  inverse  of  the  usual  approach! 
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The  dynamic  realism  needed  to  place  decision  makers  in  a  real¬ 
istic  decision-making  environment  will  be  achieved  by  means  of  an 
event-store  technique.  The  five  classes  of  events  of  which  the  event 
threads  will  be  composed  are  defined  and  the  logical  flow  of  the  event 
store  simulation  is  illustrated.  A  concept  for  incorporating  a  wide 
range  of  scenarios  is  presented  and  the  trade-offs  involved  in  ADP 
support  for  the  controllers  are  discussed.  A  sixth  class  of  event 
needed  for  operation  in  an  ADP-assisted  staff  mode  is  also  defined. 

A  basic  system  concept  is  presented  in  Section  4  and  the  re¬ 
lationship  of  the  event  classes  to  the  simulation  components  is  de¬ 
fined.  A  careful  distinction  is  drawn  between  portions  of  the  simula¬ 
tion  that  will  be  "hard  wired"  and  those  that  will  be  readily 
addressable  as  inputs.  Examples  are  given  of  both  kinds  of  para¬ 
meters  and  the  discussion  shows  why  the  cost  effectiveness  of  the 
simulation  is  determined  by  the  wise  choice  of  hard  wired  components. 
The  data  organization  is  outlined  and  the  requirement  for  and  the 
manner  in  which  the  real  data  base  and  the  Blue  and  Red  perceived 
data  bases  will  be  organized  is  shown.  The  specific  features  to  be 
included  in  the  initial  implementai ton  are  described  as  are  the  trade¬ 
offs  involved  in  deferring  some  features  for  future  extensions. 

This  is  followed  by  a  discussion  of  the  design  of  live  staff 
modules.  The  question  of  the  tradeoff  between  module  size  and  realism 
is  addressed.  The  issue  of  the  complexities  introduced  by  alternative 
(adaptive)  man-machine  interface  definition  is  raised  again.  It  is 
indicated  that  live  staff  modules  may  be  essentially  a  complete  oper¬ 
ating  shift  less  t.he  lower  (communication)  staff  processes  which  will 
be  incorporated  into  the  simulation  proper  in  the  interest  of  economy. 
This  is  followed  by  a  discussion  of  the  control  parameters  that  are 
incorporated  in  the  design  to  facilitate  employment  of  the  simulation 
for  behavioral  research.  The  final  section  of  the  report  repeats 
much  of  the  preceding  design  information  in  the  context  of  the  de¬ 
tailed  design  of  the  live  G2  module. 

Appearing  in  a  companion  volume  to  this  report  is  detailed 
design  information  on  the  staff  module  inputs  and  outputs,  the  detailed 
specifications  for  each  of  the  event  classes  and  event  thread  charts 
for  all  interface  events. 
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THE  PROBLEM 


2.1  STATEMENT  OF  THE  PROBLEM 

The  problem  addressed  in  this  research  may  be  stated  as  follows 
To  develop  a  battle  simulation  which  will  provide  a  cost-effective 
tool  for  use  as: 

•  A  systems  measurement  bed  for  behavioral  science  re¬ 
search  on  human  performance  in  the  division  command 
group  and  the  principle  staff  sections. 

•  An  aid  in  analysis  and  evaluation  of  tactics  and  doc¬ 
trine  in  combat  developments. 

•  A  training  device  for  command  groups  and  staff  elements. 

2.2  OBJECTIVES 

The  technical  objectives  of  this  effort  are: 

•  To  develop  a  top-down  design  for  an  integrated  family  of 
modular  division-level  battle  simulations  which  sepa¬ 
rately  or  jointly  will  exercise  players  performing 
critical  functions  in  command  and  control. 

•  To  develop  detailed  design  specifications  for  the  In¬ 
telligence  Staff  module  of  the  integrated  battle  sim¬ 
ulation. 

•  To  develop,  implement,  and  demonstrate  the  Intelligence 
Staff  module  as  a  stand-alone  battle  simulation  for 
research,  development,  and  training  of  Intelligence 
functions  and  for  subsequent  integration  with  other 
modules. 

2.3  MODELING  REQUIREMENTS 

Both  the  statement  of  the  problem  and  the  technical  objectives 
require  that  the  simulation  be  interactive  and,  thus,  have  man  (i.e.. 
one  or  more  decision  makers)  "in  the  loop". 

Figure  2-1  illustrates  the  basic  elements  of  any  interactive 
combat  simulation.  A  scenario,  which  specifies  forces,  situation,  and 
missions  provides  the  initial  conditions  and  the  constraints  imposed 
on  the  decision  makers.  In  the  general  case,  two  opposing  decision 
makers  feed  decisions  to  and  receive  feedback  from  a  decision  outcome 
generator.  The  latter  also  calculates  the  combat  outcomes  in  terms 
of  the  measures  of  effectiveness  being  used  to  assess  the  final 
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(battle)  outcomes.  For  some  applications,  the  functions  of  the  op¬ 
posing  (Red)  decision  maker  may  be  incorporated  into  the  decision 
outcome  generator  (usually  termed  "control").  Such  applications  might 
include  studies  of  the  nature  of  the  player-invoked  information 
processes  and  decisions  made  as  a  result  of  a  predetermined  sequence 
of  tactical  events.  They  might  also  include  cases  in  which  the  de¬ 
cision  maker  is  being  trained  to  perform  a  prescribed  series  of  in¬ 
formation  processes  or  indoctrinated  ("programmed")  to  make  certain 
decisions  in  response  to  selected  tactical  events. 

It  should  be  noted  that  for  such  an  interactive  combat  simu¬ 
lation,  the  simulation  proper  incorporates  only  the  scenario  (input 
data),  the  decision  outcome  generator,  and  the  combat  outcomes  (output). 
The  boxes  occupied  by  the  decision  makers  are  not  simulated  but  real. 
This  means  that  the  data  exchange  between  the  player  boxes  and  the 
simulation  proper  is  a  crucial  factor  in  the  design  of  the  simulation. 
This  is  discussed  in  greater  detail  in  the  following  paragraph. 

2.4  DATA  FLOW  REQUIREMENTS 

The  requirements  imposed  by  the  problem  and  objectives  stated 
above  fall  under  two  general  headings.  The  first  is  a  requirement  to 
simulate  combat  and  the  other  events  that  result  from  player  decisions. 
The  second  must  concern  itself  with  the  information  flow  and  decision 
making  inherent  in  the  division  command  post.  Since  provision  must 
be  made  for  manning  only  a  part  of  the  command  post,  i.e.,  or^  or  more 
staff  modules,  there  is  a  requirement  for  modeling  or  simulating 
those  portions  of  the  division  command  group  and  staff  sections  that 
are  not  manned  by  human  decision  makers  (players).  In  other  words, 
there  is  a  requirement  for  a  simulation  of  portions  of  the  division 
command  and  staff  quite  distinct  from  the  requirement  to  simulate 
combat. 


2.4.1  Information  Flow  and  Decision  Making 

2. 4. 1.1  Man  in  the  Loop.  All  three  of  the  applications  cited  in  the 
problem  statement  require  that  the  tool  or  test  bed  be  built  around  one 
or  more  human  decision  makers.  This  statement  is,  in  itself,  trans¬ 
parently  obvious,  but  some  of  its  implications  may  not  be.  Two 
functionally  distinct  groups  can  be  identified  in  any  combat  force 

and  might  be  called  managers  and  effectors,  Managers  are  concerned 
primarily  with  decision  making  under  conditions  of  uncertainty  and 
with  the  acquisition  of  data  which  reduce  that  uncertainty,  i.e.,  pro¬ 
vide  information.  Effectors  are  concerned  primarily  with  the  trans¬ 
lation  of  data  received  from  the  manaaers  into  physical  processes 
which  can  also  create  reportable  events.  A  combat  simulation 
substitutes  data  processes  for  the  physical  processes  of  real  combat. 

In  other  words,  the  simulation  accepts  the  data  generated  by  the 
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managers  and,  in  turn,  generates  the  data  provided  to  them  by  the  ef¬ 
fectors  and  by  other  manaqers.  The  facet  of  the  problem  addressed 
here  arises  from  the  fact  that  the  simulation  of  physical  processes 
may  not  proceed  at  the  same  rate  as  the  physical  processes  being 
simulated.  Most  computer  simulations  of  combat  run  at  many  times  the 
rate  of  the  processes  beinq  simulated.  Some  manually  assessed  war 
games  run  at  rates  far  slower  than  the  combat  being  simulated. 

However,  when  the  manager  whose  decision  making  is  under  scrutiny  is 
actually  "in  the  loop",  combat  interactions  being  simulated  must,  for 
many  applications,  proceed  at  the  same  pace  that  they  would  in  actual 
combat,  else  the  decision  maker  is  not  in  a  realistic  decision  making 
environment.  Unfortunately,  combat  is  not  as  gentlemanly  as  chess 
and  interactions  do  not  stop  while  decision  makers  make  up  their 
minds.  There  are,  of  course,  exceptions  to  this  general  rule.  For 
example,  during  the  planning  stages  of  a  military  operation,  the 
coupling  between  the  ongoing  combat  interactions  and  the  planning 
process  are  normally  not,  or  should  not  be,  nearly  so  tight  as  during 
the  implementation  stage  of  that  same  plan.  Hence,  the  combat  inter¬ 
action  might  well,  in  the  interest  of  economy,  run  faster  than  a  real 
world  pace  between  plan  completion  and  plan  implementation.  On  the 
other  hand,  in  a  training  situation,  it  might  be  desirable  to  slow 
combat  interaction  to  facilitate  the  learning  process. 

Sackman*,  from  studies  of  the  SAGE  system,  was  the  first  to  set 
forth  some  general  principles  concerning  the  dialogue  between  a  human 
decision  maker  and  a  simulation.  Although  couched  in  the  terms  of  the 
human/computer  dialoque,  his  principles  are  equally  applicable  to  the 
more  general  problem  of  man  interfacing  with  any  simulation: 

•  Real  Time  Parallelism:  Real  time  digital  events  should 
operate  in  parallel  with,  and  reflect  the  pacing  of,  the 
separate  and  distinct  real  time  characteristics  of  the 
men,  equipment,  and  relevant  situation  events  required  to 
meet  system  goals.  This  parallelism  should  hold  through¬ 
out  the  range  of  system  capacity  and  associated  computer 
operating  time.  Program  design  and  control  should  accord 
ingly  have  a  structure  that  results  in  a  close  empirical 
fit  between  digital  timing  and  environmental  timing  as 
determined  by  empirical  performance  effectiveness  thrcgh 
system  testing. 

•  Temporal  Anthropomorphism:  The  computer  system  should 
optimize  around  the  characteristic  variabilities  of  real 
time  human  norms  for  effective  system  performance  rather 
than  try  to  fit  the  human  into  an  alien  pace  that  may 
ostensibly  be  more  convenient  from  program  and  equipment 
considerations. 


Sackman.  Computers ,  System  Science  Evolving  Society.  New  York, 
John  Wiley,  1967. 


•  Conversational  Principle:  Human  performance  in  man/ 
computer  dialog  will  vary  with  the  similarity  of  the 
responding  computer  system,  to  the  real  time  exchange 
characteristics  of  human  conversation. . .As  computer 
response  time  and  message  pattern  deviate  increasingly 
from  real  time  paral lei  ism. . .so  will  user  performance 
deteriorate. .. (pp.  442-443). 

2.4.2  Modular  Structure 

A  fundamental  requirement  for  this  simulation  is  that  the 
five  basic  staff  elements  be  designed  as  independent  modules.  The 
basic  rationale  for  modularity  is  to  provide  a  means  whereby  any  one 
or  combination  of  modules  miaht  be  populated  with  live  decision  makers 
while  the  remainder  were  being  simulated.  The  modules  can  be  des¬ 
cribed  in  terms  of  the  traditional  functions  of  the  US  General  Staff 
with  Troops,  viz..  Command  Group,  G-2,  G-3,  G-l/G-4,  plus  a  Fire 
Support  Element.  Although  the  G-staff  structure  remains  a  valid 
basis  for  partitioning  staff  functions,  it  is  no  longer  the  sole 
basis  for  staff  organization  while  operating  in  the  field.  Modifi¬ 
cations  to  the  original  G-staff  structure  (borrowed  from  the  French 
Army  in  WWI)  have  appeared  at  an  increasing  rate  ever  since  the  en¬ 
try  of  the  US  into  WW  II.  Two  major  trends  have  appeared:  the  in¬ 
corporation  of  numerous  specialized  activities  into  the  command  post, 
e.g.,  fire  support,  air  defense,  signal,  etc.,  and  the  evolution 
into  a  bi-functional  staff  consisting  of  operations  and  logistics/ 
administration.  What  has  happened  is  that  the  staff  has  become  a 
matrix  organization.  Functions  are  assigned  on  a  G-staff  basis  but 
are  carried  out  in  the  new  modular  locations.  After  discussions 
with  ARI  and  with  personnel  at  the  Combined  Arms  Combat  Develop¬ 
ment  Agency  at  Ft.  Leavenworth,  the  decision  was  made  to  proceed 
with  the  traditional  G-staff  modules.  This  decision  is  discussed 
in  greater  detail  at  paragraph  3.4. 

The  extent  to  which  ancillary  functions  such  as  those  per¬ 
formed  by  the  Chemical  Biological  Radiological  Element  (CBRE), 

Division  Airspace  Management  Element  (DAME),  Tactical  Air  Control 
Party  (TACP),  Electronic  Warfare  Intelligence  Operations  Center 
(EWIOC),  etc.,  are  included  in  the  principal  staff  modules  will  be 
determined  by  the  selection  of  tactical  decision  variables  and  in¬ 
formation  messages  to  be  incorporated  in  the  simulation  (see 
paragraphs  3.1  and  3.2). 

2.4.3  Modular  Data  Flow 

The  problem  introduced  by  the  requirement  for  modularity 
must  be  defined.  If  the  test  bed  is  to  have  a  "stand  alone"  capa¬ 
bility  for  one  or  more  (but  less  than  the  totality)  of  staff  elements. 
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it  is  not  only  the  physical  processes  of  combat  that  must  be  simu¬ 
lated,  but  also  the  data  processes  performed  by  every  staff  module 
that  is  not  manned  by  human  decision  makers.  Furthermore,  this  data 
processing  must  be  in  modules  such  that  any  single  module  or  specified 
combination  can  be  replaced  by  human  decision  makers. 

The  data  flow  in  a  modular  staff  simulation  is  portrayed  at 
Figure  2-2.  The  figure  shows  a  staff  in  which  only  the  G-2  module 
is  manned;  all  other  staff  modules  are  simulations.  The  outside 
ring  of  the  figure  shows  the  data  transfers  that  must  take  place 
between  each  staff  module  and  the  world  outside  the  division  CP.  This 
outside  world  is  represented  by  the  decision  outcome  simulation.  Shown 
at  the  ring  inside  of  the  staff  are  the  internal  data  transfers  between 
the  staff  modules.  Input  and  output  arrows  connect  each  module  with 
the  internal  and  exterior  data  transfer  rings.  As  indicated,  each 
such  pair  of  arrows  is  an  interface  or  a  potential  interface  between 
a  human  decision  maker  and  the  "simulation."  The  data  processes 
and  the  data  flow  within  the  simulated  modules  do  not  have  to  duplicate 
that  of  a  real  staff  module  in  every  detail.  But,  at  every  inter¬ 
face  between  a  staff  module  and  the  information  stream,  the  simula¬ 
tion  must  provide  realistic  data  transfers  by  providing  the  data  nor¬ 
mally  available  to  decision  makers  within  the  module  and  accepting 
the  data*  generated  by  such  decision  makers.  If  the  simulation  were 
to  exercise  only  the  G-2  module  decision  makers,  only  two  sets 
of  interfaces  between  players  and  simulation  would  need  be  explicitly 
defined.  If,  however,  the  simulation  is  to  exercise  human  decision 
makers  in  any  of  the  staff  modules  or  combinations  of  the 
command  group  and  one  or  more  of  the  remaining  modules,  all  ten  of 
the  indicated  interfaces  must  be  thus  explicitly  defined"  This  is  true 
even  though  the  data  flow  into  and  out  of  a  given  staff  section  need 
not  be  as  detailed  and  complete  when  the  module  is  simulated  as  when 
it  is  occupied.  However,  provision  must  be  made  in  the  design  to 
handle  all  of  the  traffic  that  would  occur  in  the  latter  case. 

Furthermore,  if  the  staff  modules  are  to  be  indeed  modular, 
e.g,,  the  same  command  group  (CG)  module  is  employed  regardless  of 
which  other  staff  module(s)  is  populated  with  human  decision  makers, 
then  the  CG  simulation  must  be  capable  of  accepting  every  output  of 
every  other  staff  section  that  is  routed  to  it  and  it  must  be  capable 
of  generating  every  output  provided  by  CG  to  every  other  module.  By 
"capable"  is  meant  that  it  must  contain  every  format,  every  look-up 
table,  every  algorithm  (procedure)  needed  to  generate  such  outputs 
and  to  process  such  inputs.  It  does  not  mean  that  all  would  be 
exercised  if  only  one  of  the  other  modules  is  player  occupied.  If 
the  player-occupied  module  were  the  G-2  module,  the  G-2  simulation 


*The'  word  data  is  used  in  describing  modeling  procedures  even  though 
real  world  decision  makers  usually  perceive  that  they  are  providing 
information . 
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would  need  to  process  and  generate  only  the  data  exchanges  between 
6-2  and  CG  plus  those  exchanges  with  the  rest  of  the  model  that  had  the 
potential  of  generating  G-2  inputs  elsewhere. 

This,  in  turn,  '-imposes  a  substantial  burden  on  the  decision 
implementation  simulation  which  must  be  capable  of  generating  events 
at  the  finest  level  of  detail  needed  for  any  intended  application. 

No  division-level  combat  simulation  has  ever  been  built  to  handle  in¬ 
teractions  relating  to  all  major  staff  actions  at  such  a  level  of  de¬ 
tail  simultaneously.  It  appears  feasible  to  design  a  simulation  which 
would  be  sensitive  to  actions,  hence  the  performance,  of  a  principal 
staff  officer,  e.g.,  the  G-2,  but  it  does  not  appear  to  be  feasible  to 
design  one  that  would  at  the  same  time  be  sensitive  to  the  performance 
of  a  G-3  file  clerk. 

2.4.4  i^rformance  Measurement 

The  need  for  performance  measurements  in  a  simulation  of  this 
type  adds  another  facet  to  the  problem.  This  question  is  further 
compounded  by  the  multiple  applications  for  which  the  simulation  is  to 
be  used.  In  order  to  examine  this  question  it  is  necessary  to  develop 
precise  definitions  of  measures  appropriate  for  evaluating  combat  ef¬ 
fectiveness  and  tactical  information  system  performance.  Effectiveness 
measures  appropriate  for  evaluating  the  outcomes  of  combat  models  are 
described  at  paragraph  2.4.6.  Performance  measures  appropriate  for 
comparing  the  performance  of  modules  within  the  information  system 
(staff  modules)  include  measurement  of  the  following: 

•  Effort  required  to  carry  out  information  processes. 

•  Time  delays  associated  with  carrying  out  information 
processes. 

•  Completeness  of  selected  information  sets. 

•  Accuracy  of  selected  information  sets. 

•  Validity  of  selected  information  sets. 

•  Numbers  of  personnel  and  equipment. 

To  measure  the  six  variables  identified  above,  it  is  necessary 
to  define  precisely  what  is  to  be  measured.  The  above  variables  are 
defined  for  this  purpose  as  follows: 

•  The  effort  required  can  be  measured  in  man-hours  of 
personnel  effort  required  to  perform  the  information 
processes  needed  to  carry  out  specified  functions  such 
as  maintenance  of  a  specified  file  or  preparation  of  a 
specified  output  and  the  frequency  with  which  selected 
files  (displays)  are  accessed. 
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•  Time  delays  can  be  measured  in  terms  of  the  time 
(usually  in  minutes)  required  to  perform  the  information 
processes  needed  to  carry  out  specified  functions  just 
as  in  measuring  effort. 

•  Completeness  of  selected  information  sets  can  be  mea¬ 
sured  by  the  presence  or  absence  of  the  data  elements 
specified  to  be  included  in  the  set.  This  implies  a 
standard  of  measurement  against  which  this  count  will 
be  made  and  this  is  established  below. 

•  Accuracy  of  selected  information  sets  can  be  measured 
by  comparing  corresponding  data  elements  of  the  se¬ 
lected  set  with  a  standard  set.  Data  elements  which 
do  not  match  exactly  are  in  error.  This  measurement 
standard  is  also  discussed  below. 

•  Validity  of  selected  information  sets  is  defined  as  the 
combination/intersection  of  the  truth  of  the  information, 
as  compared  to  ground  truth,  and  its  relevance  to  the 
decision  for  which  the  information  set  has  been  assembled. 
This  quality  of  information  cannot  be  measured  directly 

in  real  systems,  except  on  a  basis  of  experience  with 
real  or  synthetic  systems  as  will  be  pointed  out  below. 

•  Personnel  and  equipment  involved  can  be  measured 
directly. 

Havinq  defined  the  variables  to  be  measured,  it  is  necessary 
to  look  for  the  appropriate  points  within  the  system  at  which  measure¬ 
ments  can  be  made.  Numbers  of  people  and  equipment  pose  no  problem 
because  this  measurement  is  a  property  of  the  information  system 
structure  beinq  investigated  and  not  of  its  performance.  The  other 
five  variables,  however,  are  true  performance  measures  and  it  is  neces¬ 
sary  to  determine  points  at  which  or  between  which  these  variables  are 
to  be  measured.  This  illustrated  at  Figure  2-3.  Points  at  which 
measurable  data  sets  exist  (data  inputs,  files,  and  direct  outputs) 
have  been  identified  by  marking  them  with  letters  a,  Ja,  or  c.  The 
input  sets,  files,  and  data  extracts  have  been  marked  a^  to  Benote  that 
data  elements  in  these  sets  should  be  unaltered  by  any  processing  be¬ 
tween  these  points.  Data  aggregations  have  been  marked  t3  to  indicate 
that  data  elements  contained  in  this  class  of  data  sets  can  be  altered 
between  input  and  output  but  only  to  the  extent  that  output  data  ele¬ 
ments  can  be  objective  combinations  of  input  element.  Objective  is 
defined  to  mean  an  a  priori  rule  for  combinations  already  stored  in 
the  data  base  is  used.  Outputs  marked  c,  however,  contain  subjective 
combinations  of  input  data  elements  (combinations  not  stored  in  the 
data  base  in  advance)  and  new  data  elements  not  contained  in  the  data 
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base.  Data  sets  of  class  £  result  from  human  decision  making.  The 
formal  command/staff  outputs  of  the  decision  making  node  are  shown 
along  the  lower  tier  of  Figure  2-3.  They  consist  of  combinations  of 
the  indirect  outputs  which  can  be  designated  as  purely  of  class  a, 
ib,  or  £.  Appropriate  bases  for  measurements  at  each  of  the  idenTified 
measurement  points  can  now  be  established. 

Appropriate  bases  for  measuring  each  of  the  measurable  products 
are  summarized  at  Figure  2-4. 

•  Delay  time  and  effort  can  both  be  measured  between  the 
inputs  and  the  files.  Such  measurements  provide  informa¬ 
tion  on  the  delay  times  between  inputs  and  the  files 
(especially  visible  files)  and  on  the  file  maintenance 
effort.  For  data  extracts,  both  can  be  measured  either 
between  input  and  extract  or  between  file  and  extract-- 
whichever  is  more  appropriate.  For  the  remaining  output 
products  (aggregations,  estimates,  decisions,  and  recom¬ 
mendations)  both  delay  time  and  effort  are  measurable 
between  the  file  and  the  respective  output.  A  measure¬ 
ment  between  outputs  of  this  type  and  input  is  not,  in 
general,  possible  because  the  identity  of  the  original 
input  data  elements  has  been  lost. 

•  Completeness  of  files,  data  extracts,  and  data  aggrega¬ 
tions  is  directly  measurable  by  comparison  with  inputs. 

On  the  other  hand,  the  completeness  of  estimates, 
decisions,  and  recommendations  is  not  measurable  in  terms 
of  inputs  since  they  contain  data  elements  not  neces¬ 
sarily  all  derived  from  the  data  base.  Their  complete¬ 
ness,  therefore,  can  only  be  measured  on  the  basis  of 
experience  (check  lists)  and  by  counting  the  number 

of  requests  for  clarif ication  submitted  by  the  recipients 
of  such  outputs. 

•  Accuracy  of  files,  data  extracts,  and  data  aggregations 
can  also  be  measured  by  direct  comparison  with  inputs. 

The  accuracy  of  estimates,  decisions,  and  recommenda¬ 
tions,  however,  can  be  based  only  on  experience  for  the 
same  reasons  as  for  completeness. 

•  The  validity  of  the  decision  node  outputs  is  not  directly 
measurable  within  the  information  system  itself.  Since, 
by  definition,  validity  depends  on  comparing  the  truth  of 
information  with  ground  truth,  this  factor  can  be  measured 
only  with  respect  to  the  physical  phenomena  that  lie  be¬ 
yond  the  sensors  originating  the  information  at  the 
peripheries  of  the  information  system.  Only  the  physical 
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Figure  2-4.  Bases  for  Measurement. 


results  of  decisions  are  measurable  physical  quantities 
and  these  again  lie  outside  the  confines  of  the  informa¬ 
tion  system.  It  is  this  factor  that  indeed  requires  an 
effectiveness  model  to  relate  information  system  per¬ 
formance  to  combat  effectiveness.  Any  attempts  at 
direct  measurement  of  the  validity  of  information  out¬ 
puts  or  of  files,  therefore,  can  be  based  only  on  ex¬ 
perience. 

The  implications  for  performance  measurement  for  each  of  the 
three  applications  listed  at  paragraph  2.1  can  now  be  addressed. 

•  Behavioral  science  research  on  human  performance.  For 
this  application  the  primary  emphasis  will  certainly  be 
on  measurement  of  the  performance  of  players  in  one  or 
more  staff  modules  in  terms  of  the  six  variables  defined 
above.  Measurement  of  combat  effectiveness  will,  in 
general,  be  required  only  for  those  measurements  which 
Figure  2-4  indicates  "experience"  as  the  basis  for  mea¬ 
surement.  In  those  cases  where  experience  will  no  suf¬ 
fice,  combat  outcomes  will  have  to  be  invoked.  It  must 
be  noted  that  combat  outcome  is  a  far  less  sensitive  mea¬ 
sure  than  direct  measurement  of  the  data.  Application  of 
the  simulation  for  this  purpose  will  also  require  control 
of  extraneous  variables  as  closely  as  possible.  For  ex¬ 
ample,  it  may  be  desirable  not  to  have  a  discrete  opposing 
"Red"  player  in  such  a  simulation,  but  to  control  Red  inputs 
very  closely  so  as  to  force  the  decision  making  situations 
it  is  desired  to  study.  In  fact,  for  some  research  of  this 
kind  it  may  not  be  necessary  to  have  a  truly  interactive 
simulation  at  all;  many  such  investigations  can  be  per¬ 
formed  from  a  completely  preset,  or  "canned",  sequence 

of  events. 

•  Analysis  and  Evaluation  of  Tactics  and  Doctrine,  This 
application  can  be  in  either  of  two  "contexts.  The  first 
is  an  examination  of  the  impact  of  new  tactics  and  doc¬ 
trine  on  the  staff  itself.  This  is  an  extension  of  the 
behavioral  research  described  above.  In  fact,  it  lies 
at  the  opposite  extreme  from  the  point  of  view  of  per¬ 
formance  measurement.  The  evaluation  of  tactics  and 
doctrine  on  the  outcome  of  the  battle  is  not  accomplished 
by  measuring  the  completeness,  accuracy,  validity,  or 
timeliness  of  staff  outputs,  nor  the  effort  required  to 
produce  them.  For  this  application,  one  is  primarily 
interested  in  combat  outcomes  and  measurement  of  changes 
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in  combat  effectiveness  resulting  from  changes  in  tac¬ 
tics  and  doctrine.  For  this  purpose,  the  presense  of  an 
opposing  "Red"  player  is  almost  a  necessity  becuase  tac¬ 
tics  and  doctrine  cannot  be  evaluated  solely  in  terms  of 
their  effectiveness  against  existing  enemy  doctrine,  but 
must  also  consider  the  adjustment  to  new  tactics  and 
doctrine  that  a  reasonably  intelligent  opponent  can  be 
expected  to  make.  This  application  is  truly  a  study  of 
war  rather  than  of  staffing  for  war. 

•  Training  device.  This  application  encompasses  features 
of  Both  the  above  applications.  For  teaching  staff  pro¬ 
cedures  and  the  mechanics  of  staff  processes,  measurement 
of  the  performance  of  the  various  staff  operations  is 
paramount.  On  the  other  hand,  when  teaching  the  doc¬ 
trinal  and  policy  bases  for  decision  making,  demonstra¬ 
tion  of  the  relation  between  decisions  and  combat  out¬ 
comes  is  certainly  a  preferred  training  technique. 
Historically,  in  the  absence  of  simulations  useable 
for  this  purpose,  Army  training  in  command  and  tactical 
decision  making  has  substituted  the  instructor's  experi¬ 
ence  and  judgment  for  combat  outcomes.  Student  per¬ 
formance  was  measured  against  the  "school  solution." 
Employing  a  battle  simulation  to  evaluate  the  student's 
solution  certainly  offers  a  more  efficacious  training 
device.  However,  in  this  case,  the  instructor  himself 
may  prefer  to  act  as  the  opponent  in  order  to  induce  the 
particular  training  situation  and  teaching  point  desired. 
Hence,  a  simulation  for  this  application  needs  to  pro¬ 
vide  measures  of  performance  of  the  kind  discussed  above 
and  measured  effectiveness  as  discussed  in  paragraph 
2.4,6  below. 

2.4.5  Automated  Tools  for  Players 

One  of  the  requirements  of  the  design  is  that  it  must  allow 
for  the  use  of  automated  systems  and  tools  by  the  players  as  well 
as  the  use  of  an  automated  system  to  support  the  control  and  play 
of  an  exercise.  This  requirement  adds  still  another  dimension  to 
the  problem  of  information  flow  and  decision  making  for  the  simula¬ 
tion.  If  the  automated  tools  and  system  were  completely  self  con¬ 
tained  within  one  of  the  player  occupied  staff  modules,  it  would, 
of  course,  not  impact  on  the  design  of  the  simulation  (e.q.,  a  desk 
top  calculator  used  by  the  G-3  in  the  preparation  of  a  movement 
schedule).  Such  a  restriction  would,  however,  be  very  limiting  and 
the  intent  is  to  highlight  the  requirement  to  study  human  factors 
and  staff  performance  and  to  train  staff  members  when  the  staff 
module  is  being  assisted  by  an  ADP  system  such  as  the  Tactical  Op¬ 
erations  System  (TOS)  which  serves  more  than  one  staff  module  by 
means  of  a  shared  data  base  and  processing  facilities. 


Figure  2-5  illustrates  the  information  flow  in  the  elementary 
decision  node  when  ADP  is  added  to  the  node.  It  will  be  noted  that 
some  information  continues  to  flow  through  the  Level  I  (Receive  and 
Transmit)  processes  which  can  be  thought  of  as  manual  interface  de¬ 
vices  (radio,  telephone,  teletypewriter,  etc.).  On  the  other  hand, 
for  that  information  which  comes  in  or  is  transmitted  via  the  ADP  sys¬ 
tem,  new  interfaces  with  manual  processes  must  be  developed  through 
new  input/output  devices,  i.e.,  computer  terminals.  It  should  also 
be  noted  that  the  information  traversing  these  interfaces  may  be  at 
levels  higher  than  Level  I  and  is  no  longer  restricted  to  the  forms 
associated  with  the  manual  system.  In  other  words,  the  information 
that  passes  into  the  manual  part  of  the  decision  making  node  from  A DP 
terminals  is  already  selectively  retrieved  and  may  be  aggregated.  As 
such  ADP  systems  are  currently  designed,  capability  to  use  the  data 
base  for  higher  level  operations  is  limited  except  as  such  information 
is  added  in  free  text,  consequently,  capability  to  process  such  in¬ 
formation  is  also  very  limited.  Nevertheless,  such  a  combined  system 
will  now  have  a  dual  data  base,  part  manual  and  part  automated. 
Clearly,  the  manual  process  configuration  will  change  provided  the 
manual  elements  within  the  note  perceive  some  advantage  to  using  the 
ADP  to  process  some  portion  of  the  information  flow.  It  is  also 
clear  that  a  precisely  defined  standing  operating  procedure  must 
specify  which  information  will  be  processed  manually  and  which  will 
be  processed  'i  part  through  ADP. 

The  gravity  of  the  problem  raised  by  this  requirement  now 
becomes  apparent.  Clearly,  any  information  transferred  through  an 
automated  terminal  must  exist  on  the  simulation  side  of  the  inter¬ 
face  in  digital  form.  Thus,  the  simulation  must  contain  the  data 
bases  and  automatic  data  processing  that  would  support  automated 
interface  devices.  On  the  other  hand,  if  the  players  are  operating 
without  ADP  assistance,  this  same  information  must  be  transferred 
through  manual  input/output  devices.  Thus,  the  interface  specifica¬ 
tion  must  be  variable  to  reflect  varying  degrees  of  ADP  assistance 
to  players,  but  the  simulation  must  have  the  capability  to  process  in 
digital  form  the  maximum  scope  of  information  that  it  might  ever  be 
desired  to  provide  through  automated  terminals. 

2.4.6  Effectiveness  Measures 


This  discussion  is  concerned  with  the  requirement  for  measuring 
the  outcomes  of  combat  models  as  distinguished  from  the  measurement 
of  performance  within  the  information  and  decision  making  simulation 
which  was  discussed  at  paragraph  2.4.4  above. 

The  outcomes  of  combat  can  be  distinguished  through  quantita¬ 
tive  comparisons  of  three  factors: 

t  Changes  in  the  geographic  area  controlled  by  both  sides. 
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•  Changes  in  the  resources  available  to  both  sides. 

•  Time  intervals  required  to  effect  the  above  changes. 

Tiede  (1967)  has  demonstrated  that  ground  force  missions  specify  accept¬ 
able  changes,  i.e.,  specify  constraints,  in  these  three  factors.'  The 
same  reference  also  indicates  that  one  of  two  objective  functions  may 
be  associated  with  each  military  mission: 

•  Minimization  of  resource  expenditure  for  missions  re¬ 
quiring  engagement  of  the  bulk  of  the  available  force 
(e.g.,  area  defense  or  penetration). 

•  Maximization  of  area  controlled  for  missions  requiring 
engagement  of  small  portions  of  the  force  (e.g.,  delay 
or  exploitation). 

Comparisons  of  combat  outcomes  in  the  a  terms  is  conceptually  simple 
and  straightforward  but  the  quantification  of  these  outcomes  is  fre¬ 
quently  difficult. 

Measurement  of  time  intervals  poses  no  problem.  There  are  no 
great  difficulties  in  measuring  times  between  events  (e.g.,  changes  in 
resources  and  in  area),  provided  there  are  means  for  determining  that 
those  events  have  indeed  occurred. 

Measurement  of  changes  in  resources  has  until  recently  posed 
a  fundamental  difficulty  even  though  there  is  no  conceptual  difficulty 
in  measuring  resources.  The  problem  has  been  that  this  factor  is 
really  a  multi-dimensional  function  with  no  generally  accepted  method 
of  aggregating  resources  of  different  kinds.  For  example,  a  solution 
within  constraints  that  expends  50  lives  and  10  tanks  has  minimized 
resource  expenditure  with  respect  to  one  that  expends  50  lives  and  20 
tanks.  But  where  is  one  ranked  that  expends  55  lives  and  5  tanks? 

"Total  resources  expended"  cannot  be  calculated  as  a  single  quantity 
unless  values  are  assigned  to  the  various  classes  of  resources. 

A  recently  developed  methodology  called  Analysis  of  Military  Organi¬ 
zational  Effectiveness  Methodology  (AM0RE)2  does  enable  one  to  combine 
different  classes  of  resources  into  a  single  measure,  i.e.,  potential 
unit  effectiveness. 

For  area  controlled  by  a  military  force,  there  is  a  similar 
difficulty.  Again,  as  for  resources,  we  have  really  defined  an  area- 
of-control  function— not  a  method  for  aggregating  areas  of  widely 
different  characteristics  and  hence  military  values.  At  this  stage, 
this  difficulty  can  be  overcome  only  on  a  case-by-case  basis,  as  was 

^R.V.  Tiede,  "A  Formulation  of  Ground  Combat  Missions  in  Mathematical 
Programming  Form,"  RAC-TP-265,  Research  Analysis  Corporation,  July  1967. 

2g.  Page  and  S.  Rose,  "Analysis  of  Military  Organizational  Effective¬ 
ness  (AMORE),"  proceedings  of  the  42d  Military  Operations  Research 
Symposium,  December  1978. 


2-17 


suggested  for  varying  classes  of  resources.  It  is  hoped  that  the  mis¬ 
sion  statement  will  specify,  or  a  combat  simulation  will  demonstrate, 
the  relative  vaues  of  controlling  different  subareas.  Against,  we 
know  from  experience  that  the  values  of  certain  key  terrain  features 
may  be  so  high  as  to  dominate  a  much  larger  area. 

The  preceding  brief  review  of  some  of  the  factors  involved  in 
quantifying  the  outcomes  of  combat  shed  some  light  on  the  output  re¬ 
quirements  for  a  combat  simulation.  Clearly,  the  status  of  resources 
on  both  sides  of  the  conflict  must  be  quantified  both  in  terms  of 
expenditures  and  replacements.  For  division-level  combat,  the  re¬ 
sources  to  be  accounted  for  must  include  personnel,  major  weapons 
(e.g.,  tanks,  APCs,  artillery  tubes  and  launchers),  ammunition  by  major 
category  (individual  weapons  if  tactical  nuclear  war  is  to  be  simulated), 
and  POL.  Such  resource  data  will  permit  calculation  of  exchange  ratios 
which  may  be  an  important  criterion  for  some  comparisons.  Maintaining 
resource  data  at  a  level  of  resolution  much  finer  than  indicated  poses 
difficult  data  management  problems  which  are  justified  only  for  special 
applications. 

The  area  controlled  by  both  forces  is  another  needed  output. 

This  is,  in  general,  a  more  complicated  problem  than  keeping  track  of 
FEBA  changes.  FEBA  change  is  an  adequate  measure  for  i.iissions  in 
which  the  division  is  heavily  engaged  in  an  essentially  flankless  en¬ 
vironment.  However,  even  for  many  conventional  engagements  in  more 
open  warfare  (e.g..  Middle  East,  Vietnam,  or  even  the  North  German 
Plain)  other  measures  must  be  provided.  It  is  necessary  to  have  means 
for  determining  which  side  controls  key  terrain  features  such  as 
dominant  ridge  lines,  bridges,  defines,  key  roads,  communication 
centers,  etc. 

Finally,  if  the  dynamics  of  combat  are  to  be  simulated,  as  is 
almost  always  the  case  for  studies  of  changes  in  performance  within 
the  tactical  information  and  decision  making  system,  there  must  be  means 
for  recording  time  intervals  between  events.  This  can  be  done  either 
by  recording  status  at  predetermined  time  intervals  or  by  recording  the 
time  at  which  selected  events  occur. 

2.5  FUNCTIONAL  REQUIREMENTS 

From  the  preceding  discussion  we  can  now  define  the  functional 
modeules  that  must  be  contained  in  the  simulation.  The  simulation  proper 
must  contain  a  maximum  of  seven  modules  (Figure  2-6).  These  are  : 

•  A  Command  Group  Module, 

•  A  G-2  Module, 
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Figure  2-6  .  Overview  of  the  Simulation. 


•  A  G-3  Module, 

•  An  FSCE  Module, 

•  A  G-l/G-4  Module, 

•  A  Decision  Outcome  Module,  and 

•  A  Red  Command  Group  Module. 

The  seventh.  Red  Command  Group,  module  may  be  combined  with  the  Decision 
Outcome  module  for  some  applications  to  reduce  the  overhead  costs  of 
operating  the  simulation,  but  must  nevertheless  be  designed  so  that  it 
will  be  available  for  those  applications  that  require  it. 

For  the  live  staff  modules,  the  design  must  include  a  detailed 
definition  of  the  man/simulation  interface  for  each  of  the  five  staff 
modules  and  the  Red  Command  Group.  For  the  five  Blue  staff  modules, 
the  design  must  also  provide  the  needed  internal  instrumentation  as 
discussed  in  paragraph  2.4.5  above. 
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ANALYSIS  OF  SIMULATION  REQUIREMENTS 
3.1  DESIGN  PRINCIPLES 

The  discussion  of  the  problem  in  the  preceding  section  has 
made  it  clear  that  the  simulation  needed  to  achieve  the  design  goal 
is  a  rather  specialized  information  system.  It  must  be  capable  of: 

•  Accepting  and  implementing  the  decisions  made  by  human 
players  in  one  or  more  modules  of  the  Blue  division  staff. 

0  Simulating  those  processes  that  will  produce  feedback  to 
the  selected  staff  module(s). 

0  Generating  and  presenting  the  feedback  at  the  appropriate 
time  and  in  a  realistic  manner. 

0  Calculating  the  final  outcome  of  the  battle  being  simu¬ 
lated  in  terms  of  the  selected  measures. 

#  Measuring  the  human  performance  within  the  selected 
staff  module(s) . 

Of  these  five  requirements,  the  first  four  are  highly  interrelated  and 
determine  the  design  of  the  simulation  proper.  The  fifth  is  concerned 
primarily  with  instrument ng  the  non-simulated  portion  and  is  related 
to  the  first  four  only  insofar  as  the  simulation  must  provide  some 
of  the  data  points  needed  to  measure  human  performance. 

In  developing  the  design  concept,  the  following  principles 
have  been  followed: 

1 .  For  each  Blue  staff  module  and  for  the  Red  command  mod¬ 
ule,  the  selected  decision  variables  and  their  associated 
input  and  output  messages  establish  the  scope  of  the 
simulation. 

The  application  of  this  principle  requires  definition  of  some  of  its 
terms.  An  input  is  defined  as  an  inbound  data  package  (message)  re¬ 
ceived  by  a  staff  module.  An  output  is  defined  as  an  outbound  data 
package  (message)  transmitted  outside  the  staff  module.  A  decision 
variable  is  defined  as  any  decision  class  or  type  that  results  in  one 
or  multiple  outputs.  It  may  be  as  simple  as  a  decision  to  disseminate 
an  incoming  message  to  another  staff  module  or  as  complex  as  a  formal 
operations  plan  or  order.  However,  once  the  range  of  decision  variables 
to  be  included  in  the  simulation  has  been  established  together  with 
their  associated  outputs  and  the  inputs  needed  to  make  those  decisions, 
the  scope  of  the  entire  simulation  has  been  set.  In  order  to  appre¬ 
ciate  this  fact,  one  must  realize  that  every  input  is  but  a  report  of 
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an  event  whether  that  event  was  triggered  exogenously  to  the  simula¬ 
tion  by  the  scenario  or  internally  by  the  clock  or  through  interac¬ 
tion.  In  a  sense,  the  outputs  and  inputs  selected  as  a  result  of  the 
choice  of  decision  variables  comprise  the  "meta-language"  through 
which  the  players  and  simulation  communicate.  It  should  be  noted  that 
this  is  the  reverse  of  the  usual  approach  to  scoping  a  battle  simula¬ 
tion  or  war  game.  The  more  usual  approach  is  to  select  the  range  of 
scenarios  and  interactions  to  be  encompassed  and  then  to  design  an 
information  system  which  will  make  it  play. 

2.  The  selected  inputs,  outputs,  and  their  associated 
events  are  tied  together  by  means  of  event  threads 
which  fix  their  sequence  and  time  of  occurrence. 

The  application  of  this  second  principle  determines  the  level 
of  resolution  of  the  simulation  in  terms  of  the  unit  size  of  the  forces 
carried  in  the  data  base,  the  state  variables  needed  to  describe  those 
units,  the  unit  of  resolution  of  those  state  variables,  as  well  as 
the  needed  time  resolution.  This  follows  directly  from  the  concept 
that  each  input  to  a  staff  module  is  the  report  of  an  event.  Thus, 
the  reportable  events  determine  the  level  of  aggregation  that  can  be 
tolerated.  For  example,  it  is  unlikely  that  any  selected  input  will 
require  the  reporting  of  an  individual  rifle  shot.  For  purposes  of 
reporting  ammunition  expenditure,  aggregation  of  rifle  firing  to  bat¬ 
talion  level  at  three  hour  intervals  may  suffice.  On  the  other  hand, 
for  the  purpose  of  reporting  an  initial  contact  with  the  enemy,  ag¬ 
gregation  of  individual  rifle  firing  may  be  possible  only  to  company 
level  and  the  report  may  be  triggered  by  a  transition  in  posture  from 
"moving  (in  APCs)"  to  "engaged,"  and  may  need  to  be  reported  to  the 
nearest  minute. 

3.  The  simulation  must  contain  every  event  thread  needed 
for  every  input/event/output  relationship. 

This  principle  simply  means  that  the  simulation  must  be  capable 
of  accepting  and  implementing  the  totality  of  the  selected  decision/ 
outputs.  It  must  also  be  capable  of  triggering  every  reportable  event 
whether  triggered  by  interaction,  the  scenario,  or  the  clock.  While 
the  totality  of  all  event  threats  must  be  made  explicit  within  the 
simulation,  not  all  such  event  threads  will  necessarily  be  activated 
in  every  application.  It  is  possible  that  some  event  threads  will 
have  the  property  of  being  connected  to  less  than  the  full  set  of 
staff  modules.  Such  event  threads  would  be  activated  only  if  needed 
to  process  inputs  and  outputs  from  live  staff  modules. 

Table  3-1  illustrates  how  the  design  requirements  imposed  by 
the  application  of  the  above  principles  apply  to  each  of  the  seven 
simulation  modules  shown  at  Figure  2-6. 
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3.2  DECISION  VARIABLES  AND  INPUT/OUTPUT  FORMATS 

This  section  describes  the  manner  in  which  the  decision  vari¬ 
ables,  staff  inputs,  and  the  formats  for  each  were  defined  and  selected. 

3.2.1  Decision  Outputs 

Decision  variables  are  defined  as  any  decision  class  or  type 
that  results  in  one  or  multiple  outputs.  Having  made  that  defini¬ 
tion,  it  is  clear  that  there  is  a  one-to-one  correspondence  between 
decision  variables  and  output  classes.  Table  3-2  is  an  example  of 
such  a  listing  of  decision  variables  (or  decision  outputs)  for  the 
G-2  section.  They  have  been  broken  down  into  major  types  with  a 
further  breakout  by  output  content.  Shown  for  each  is  the  trigger 
event  which  causes  each  output  to  be  produced  and  the  usual  ad¬ 
dressees.  Similar  listings  were  prepared  for  each  of  the  other 
modules  (Cmd  Grp,  G-3,  G-l/G-4  and  FSCE)  and  are  listed  in  Design 
Notes  A,  B,  and  C. 

3.2.2  Decision  Inputs 

Shown  at  Table  3-3  is  a  listing  of  the  classes  of  inputs  to 
the  G-2  section.  Shown  alongside  each  input  class  are  the  usual 
sources  for  each.  The  remainder  of  the  table  is  a  matrix  which  shows 
the  relationship  between  G-2  inputs  (rows)  and  G-2  outputs  (columns). 

The  "X"  entries  denote  which  inputs  can  provide  data  for  each  output. 

The  inputs  and  outputs  define  the  interface  requirements  for  a  live 
G-2  staff  module.  The  matrix  indicates  which  inputs  must  be  connected 
with  which  outputs  by  event  threads  when  the  G-2  module  is  being  simu¬ 
lated.  Similar  matrices  have  been  prepared  for  all  staff  modules  and 
are  contained  in  Design  Note  C. 

3.2.3  Rationale  for  Format  Development 

Having  developed  reasonably  comprehensive  lists  of  inputs  and 
outputs  of  which  an  example  is  shown  at  Table  3-3,  these  were  sub¬ 
jected  to  a  three-stage  screening  process  in  the  course  of  developing 
the  simulation  formats.  These  steps  are: 

t  Classification  with  respect  to  simulation  requirements, 

t  Classification  with  respect  to  running  time. 

0  Classification  by  formatting  requirements. 

Each  of  the  above  provides  a  basis  for  reducing  the  number  of  data  ex¬ 
changes  that  will  actually  be  required  in  the  simulation. 
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Table  3-2  G-2  Decision  Outputs. 


OUTPUT  TYPE 

CONTENT 

TRIGGER 

DISTRIBUTION 

Recurrinq  Reports 

Intelligence  Summary 

Clock  (SOP) 

1,  2,  3 

Para  1,  SITREP 

Clock  (SOP) 

G-3 

Weather  Forecast 

Weather  Forecast 

2,  3 

As  Required 

Intelligence  Report 

Own  Initiative 

1,  2,  3 

Reports 

INTEL  Estimate2 

CG  Guidance 

2 

COUNTERINTEL  Est. 

CG  Guidance 

2 

INTEL  Annex3 

CG  Guidance 

G-3 

Spot  Reports 

NBC  1 

NBC  1 

1,  2,  3 

Retransmit  Spot  Rpt 

Incoming  Spot  Rpt  2 

Query4 

Own  Initiative 

1  or  2  or 

3 

Response4 

Query 

1  or  2  or 

3 

Fraq  Orders 

Revise  EEI 

CG  Guidance 

2,  3 

Revise  Tasking 

CG  Guidance  or 

2,  3 

Spot  Report 

Special 

Request 

Own  Initiative 

2 

Response 

Request 

2 

1.  Distribution  Code: 

1  -  Higher  HQ 

2  -  All  other  staff  modules 

3  -  Subordinate  Units 

2.  Includes  Analysis  of  Area  of  Operations. 

3.  Includes  new  EEI  and  tasking. 

4.  Queries  and  responses  may  be  sent  to  any  addressee  in  the  distri¬ 
bution  code  and  may  concern  any  legitimate  area  of  G-2  responsi¬ 
bility.  Coordination  actions  by  other  staff  modules  will  also  be 
handled  as  queries  and  responses. 
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The  first  classification  was  accomplished  as  shown  at  Table 
3-4.  This  table  indicates  that  there  are  three  classes  of  outputs  and 
three  classes  of  inputs.  The  grouping  shown  is  on  the  basis  of: 

a  No  interaction  with  the  simulation. 

a  Interaction  with  other  staff  modules. 

A  Interaction  directly  with  the  decision  outcome  generator. 

It  will  be  noted  immediately  that  the  class  of  outputs  labeled  "external 
transmissions"  do  not  need  to  be  in  a  form  assimilable  by  the  simulation. 
In  fact,  they  will  be  ignored  by  the  simulation  and  will  be  generated 
only  by  live  staff  modules.  Their  content  and  time  of  submission  may 
be  useful  for  evaluating  live  staff  performance.  By  the  same  token,  the 
inputs  labeled  external  message  receipt  are  not  generated  by  the  simula¬ 
tion  and  can,  in  fact,  be  part  of  the  initial  scenario  preparation. 

Such  inputs  would  not  have  to  be  strictly  formatted  for  entry  into  live 
staff  modules,  but  when  the  staff  module  is  simulated  such  entries  must 
be  assimilable  by  the  simulation.  It  should  be  noted  that  all  data  ex¬ 
changes  with  higher  headquarters  do  not  necessarily  have  to  be  of  this 
type.  For  example,  a  query  to  corps  or  a  request  for  reinforcement 
could  be  a  direct  entry  into  the  decision  outcome  generator;  in  this 
case,  a  controller  is  simulating  Corps  HQ.  The  remaining  message  ex¬ 
changes,  transmissions,  and  receipts  must  be  made  explicit  at  the  mod¬ 
ule  boundaries  so  that  any  module  can  be  populated  by  live  players. 
Furthermore  their  interconnection  with  simulated  events,  either  within 
or  other  staff  modules  or  in  in  the  decision  outcome  generator,  must  be 
establ ished. 

The  second  step  in  screening  inputs/outputs  involves  a  review 
of  the  listed  data  exchanges  to  see  which  ones  are  pertinent  within 
the  expected  running  time  of  the  simulation.  Since  the  simulation  is 
of  division  level  combat,  it  is  estimated  that  there  will  be  little 
requirement  to  run  the  simulation  for  a  time  period  (real  time  =  game 
time)  greater  than  12  hours.  On  this  basis  a  number  of  reports  gen¬ 
erated  by  staff  modules  at  periods  of  24  hours  (e.g.,  the  INTSUM)  can 
also  be  treated  as  external  transmissions.  Even  though  the  INTSUM  is 
provided  to  other  staff  modules  by  G-2,  it  is  basically  a  compilation 
of  past  events  in  a  convenient  format  for  reference.  Actually,  the 
germane  information  would  already  have  been  passed  to  the  affected 
staff  modules  as  retransmissions  of  spot  reports  or  combat  intelligence 
reports.  Thus,  the  INTSUM  can  be  treated  as  an  external  transmission 
even  though  it  is  normally  routed  to  higher  HQ,  to  subordinate  units, 
and  to  other  staff  modules.  This  means  that  only  live  staff  modules 
will  be  required  to  produce  INTSUMs  and  this  output  does  not  have  to 
be  entered  into  the  simulation.  If  it  is  needed  as  an  input  to  some 
other  live  staff  module  (e.g.,  G-3)  it  can  be  handled  as  an  external 
message  receipt,  i.e.,  prepared  in  advance  of  the  simulation,  and 
does  not  need  to  be  generated  by  the  simulation. 
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The  third  step  in. the  process  of  developing  the  final  list  of 
formats  consists  of  sorting  based  on  content.  It  is  highly  likely, 
for  example,  that  a  number  of  spot  reports  with  different  names, 
based  on  content,  can  in  fact  be  represented  by  a  single  format  con¬ 
taining  the  basic  "who,  what,  , where,  when,  why"  data.  On  the  other 
hand,  it  may  also  be  necessary  to  break  out  some  of  the  inputs  shown 
as  single  entries  in  Table  3-3  into  multiple  formats  in  order  to  ac¬ 
commodate  different  information  categories.  After  this  process  was 
completed  we  were  in  a  position  to  make  the  final  format  selection 
and  definition.  The  formats  selected  appear  at  Design  Note  D. 

3.3  DYNAMIC  REALISM 

The  realistic  time  sequencing  of  events  in  the  simulation  is 
based  on  an  event-store  technique  in  which  the  simulated  time  clock 
is  tied  to  a  real  clock  so  as  to  provide  slow  time,  real  time,  or 
fast  time  play.  The  input  to  individual  Blue  staff  modules  or  to  the 
Red  command  module,  i.e.,  the  tactical  information  messages  from  the 
field  (or  from  higher  headquarters) ,  represent  one  class  of  events 
whose  sequencing  must  fit  into  the  event-store  framework.  The  output 
directives  and  orders  from  Blue  staff  modules  to  Blue  units  in  the 
field  or  from  the  Red  command  module  to  its  subordinate  units  represent 
a  second  class.  In  addition  to  these  "interfacing"  classes,  there  are 
three  other  classes  of  events  which  must  also  be  handled  by  the  event- 
store  mechanism. 

The  five  classes  of  events  required  in  the  simulation  are  de¬ 
fined  in  Table  3-5.  Each  class  will  require  a  separate  set  of  rules 
or  algorithms  in  the  simulation,  but  all  classes  will  have  to  fit 
into  the  general  event-store  framework.  The  separate  modes  for  han¬ 
dling  the  events,  examples  of  events  in  each  class,  and  special  sim¬ 
ulation  techniques  to  be  employed  with  some  classes  are  presented  in 
paragraph  4.1. 

The  logical  flow  of  the  simulation  procedures  providing  the 
time  sequencing  of  events  is  illustrated  in  Figure  3-1.  The  process 
will  require  a  large  data  storage  array  called  the  Event  Table.  The 
table  will  contain  separate  entries  for  all  events  (of  all  five 
classes)  that  will  occur  at  some  time  in  the  future  of  the  current 
simulated  clock  reading.  Such  entries  will  be  called  "scheduled 
events".  They  will  be  extracted  from  the  table  and  the  corresponding 
entries  erased  when  the  simulated  clock  arrives  at  or  near  the  time 
associated  with  the  individual  events.  If  one  or  more  new  events 
arise  as  a  consequence  of  the  processing  of  a  scheduled  event,  these 
new  events  are  then  put  into  the  Event  table  so  that  they  become 
scheduled  for  processing  at  some  future  time  on  the  simulated  time 
clock. 
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Figure  3-1.  Logical  Flow  of  the  Event-Store  Simulation. 
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The  central  data  processing  problem  in  implementing  this  event- 
store  technique  is  the  ordering  or  arranging  of  the  scheduled  events 
so  that  they  may  be  readily  extracted  in  the  proper  time  sequence.  It 
is  estimated  that  the  number  of  entries  in  the  table  (covering  all 
classes  of  events)  will  range  between  100  and  500  durinn  any  moment  in 
the  active  play  of  the  simulated  combat.  However,  the  loading  of 
each  new  event  requires  that  the  order  of  arrangement  of  entries  be 
modified  so  that  the  correct  time  sequence  is  preserved. 

3.4  DESIGN  DECISIONS 

A  number  of  questions  arose  during  the  evolution  of  the  top 
down  design  of  the  simulation.  The  resolution  of  each  of  these  ques¬ 
tions  affected  the  overall  design  concept.  Most  of  these  were  re¬ 
solved  during  Phase  I  of  the  design  effort  and  the  decision  made  is 
discussed  below.  However,  in  two  cases  the  questions  were  not  re¬ 
solved  and  additional  design  effort  is  needed. 

3.4.1  Traditional  G  Staff  Versus  Bi-Functional  Staff 

This  question  was  raised  in  paragraph  2.4.2.  The  nature  of 
the  difficulty  can  best  be  appreciated  by  looking  at  the  staff  struc¬ 
ture  specified  by  some  of  the  current  doctrinal  literature.  This  is 
illustrated  in  Figures  3-2  through  3-5  which  have  been  extracted 
from  TC  101-5,  "Control  and  Coordination  of  Division  Operations," 

April  1976.'  Figure  3-2  shows  the  configurai ton  for  a  division  tacti¬ 
cal  command  post  (TAC).  Figure  3-3  shows  the  configurai ton  of  the 
Main  division  command  post  while  Figure  3-4  is  a  blow-up  of  the  Tac¬ 
tical  Operations  Center  (TOC)  contained  in  "Main".  It  is  immediately 
apparent  that  the  G-staff  functions  are  not  the  basis  for  organizing 
the  various  staff  activity  centers.  G-2,  G-3,  and  FSE  functions  are 
being  performed  both  at  TAC  and  at  TOC.  In  fact,  the  same  is  also 
true  of  command  group,  G-l,  and  G-4  functions,  although  to  a  lesser 
degree.  Figure  3-5  is  a  representation  of  the  locations  in  which 
G-2  functions  are  performed  which  have  been  indicated  by  cross-hatching. 
It  will  be  seen  that  G-2  functions  are  being  performed  at  four  different 
activity  centers,  three  in  TOC  and  one  in  TAC.  The  difficulty  of  de¬ 
signing  a  pure  G-2  module  now  becomes  clear.  If  the  requirements  for 
man/simulation  interface  are  to  be  met,  the  "players"  or  "subjects" 
must  be  played  in  a  realistic  operational  environment.  The  reason 
for  combining  6-2  and  G-3  elements  in  an  Op  Center  at  TOC  is  the  ex¬ 
tensive  interface  between  these  two  staff  elements  needed  for  actual 
operations.  That  interface  would  have  to  be  simulated  by  controllers 
for  a  "pure"  G-2  module. 

A  basic  principle  of  any  modular  design  is  to  draw  the  bound¬ 
aries  around  modules  so  as  to  minimize  the  interconnections  between 
modules.  A  feasible  modular  structure  that  parallels  TC  101-5  is 
depicted  at  Figure  3-6.  The  five  modules  identified  are: 
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•  Command  Group  at  TAC  (to  include  G-2/G-3/ADA/FSE/USAF 
elements) 

•  Operations  Center  at  TOC  (to  include  Reconnaissance  and 
Surveillance  element) 

•  All -Source  Intelligence  Center  at  TOC 

•  FSCE  at  Toe 

•  ADMIN,  G-l/G-4  at  TOC. 

The  above  discussion  brings  into  clearer  focus  the  problem 
raised  in  the  discussion  of  modular  structure  in  paragraph  2.4.2. 

The  identification  of  inputs  and  outputs  for  each  of  the  G-staff  ele¬ 
ments  is  fairly  straightforward  .from  the  doctrinal  literature.  This 
is  not  the  case  for  the  bi-functional  staff  described  in  TC  101-5. 

The  identification  of  the  inputs  and  outputs  for  each  of  the  staff 
modules  in  the  bi-functional  staff  is  not  spelled  out  in  the  doc¬ 
trinal  literature  and  would,  in  fact,  depend  on  the  SOPs  in  effect  in 
a  particular  division.  In  effect,  one  would  have  to  make  an  arbitrary 
assignment  of  decision  outputs  to  each  module  and  determine  the  in¬ 
puts  needed  to  support  these.  This  process  is  compounded  by  the  fact 
that  under  this  concept  the  module  boundaries  r.ow  separate  portions 
of  the  same  G-staff  module  (for  example,  G-2  activities  would  be  car¬ 
ried  on  in  three  different  modules).  This  means  that  the  data  ex¬ 
changes  between  different  portions  of  the  G-2  staff  element  would  now 
have  to  be  made  explicit  at  the  new  module  boundaries,  whereas  they 
were  implicit  within  G-2  when  it  was  a  single  module.  Thus,  the 
module  input/output  matrix  could,  in  fact  be  significantly  larger 
resulting  in  a  larger  number  of  formats  that  would  have  to  be  handled 
by  the  simulation. 

These  considerations  were  discussed  at  some  length  with  ARI 
and  jointly  with  representatives  of  ARI  and  the  Command  and  General 
Staff  College  at  Ft.  Leavenworth.  The  final  decision  was  that  the 
traditional  G  staff  organization  would  be  the  basis  for  organizing 
the  staff  modules  in  this  simulation. 

3.4.2  Nuclear  Events 


A  design  decision  was  required  with  respect  to  including 
nuclear  events  in  the  simulation.  The  inclusion  of  such  events  im¬ 
poses  the  following  additional  requirements  on  the  design  of  the 
simulation: 

•  Adds  the  requirement  for  unique  exchanges  between  staff 
modules  (Class  2  events). 

•  Adds  the  requirement  for  unique  outputs  from  the  staff 
modules  to  subordinate,  adjacent,  and  higher  head¬ 
quarters  (Class  3  events). 
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•  Adds  the  requirement  for  unique  inputs  to  the  staff 
modules  frofti  subordinate,  adjacent,  and  higher  head¬ 
quarters  (Class  4  events). 

The  above  requf rements ,  in  turn,  require: 

•  Unique  events  internal  to  the  staff  modules  for  pro¬ 
cessing  decisions  associated  with  nuclear  events 
(Class  1  events). 

•  Unique  events  internal  to  the  battle  outcome  generator 
and  the  rest  of  the  outside  world  (Class  5  events). 

•  Unique  characteristics  for  units  within  the  data  base, 
e.g. , 

Individual  nuclear  rounds  remaininq  in  nuclear 
capable  delivery  units. 

Changes  to  the  combat  effectiveness  of  combat 
units  in  a  "warned"  posture. 

Despite  the  additional  complexity  incurred  by  including  the 
capability  to  exercise  the  decision  variables  associated  with  nuclear 
warfare,  this  capability  is  of  such  importance  that  it  was  included 
in  the  simulation  design  and  the  associated  events  are  included  in  the 
detailed  annexes.  It  is,  of  course,  not  necessary  to  use  nuclear  events 
in  any  particular  scenario  if  not  required  for  the  purpose  of  the 
investigation. 


3.4.3  Simultaneous  Planning,  Execution,  and  Reporting 

Another  design  decision  concerned  the  requirement  to  exercise 
the  staff  modules  simultaneously  in  activities  associated  with 
planning  future  operations  and  executing  and  reporting  on  current  op¬ 
erations.  A  number  of  considerations  entered  into  this  decision. 
First,  staff  planning  is  normally  isolated  from  the  monitoring  of 
current  operations  because: 

•  "Operations"  is  concerned  with  the  management  of  the  ex¬ 
ecution  of  a  prior  plan. 

•  The  planning  process  is  triggered  by  an  actual  or  pro¬ 
jected  change  in  mission  and  is  based  on  (and  as  in¬ 
sensitive  as  possible  to)  assumed  future  states  (capa¬ 
bilities,  threat,  environment. 

•  Plans  are  revised  (coupled  to  real  world  states)  as 
the  time  for  execution  approaches. 

Hence,  there  is  little  requirement  for  real  time  inputs  from  the  on¬ 
going  battle  purely  for  planning  purposes. 
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The  second  consideration  was  that  computer  simulation  can  as¬ 
sist  planning  but  not  plan.  This  results  directly  from  the  fact  that 
the  degree  of  uncertainty  associated  with  planning  is  even  higher  than 
that  associated  with  execution.  After  ill,  the  decisions  required 
during  execution  concern  the  modifications  required  to  adapt  a  prior 
plan  to  the  realities  of  the  world  as  the  uncertainty  is  reduced 
through  execution.  If  the  latter  decisions  are  too  complex  to  simu¬ 
late  completely  by  means  of  computer  algorithms,  this  is  even  more 
true  of  planning  decisions. 

Finally,  the  worth  of  a  plan,  once  prepared,  can  be  evaluated 
in  only  one  of  two  ways  (see  also  the  discussion  at  paragraph  2.4.4): 

•  Comparing  it  the  "school  solution"  (experience). 

•  Implementing  it,  to  include  simulating  its  execution. 

The  above  considerations  led  to  the  basic  decision  that  the 
activities  associated  with  the  preparation  of  complete,  formal  opera¬ 
tions  plans  and  orders,  or  the  portions  thereof  assigned  to  a  partic¬ 
ular  staff  module,  would  be  performed  only  by  live  staff  modules  and 
not  by  simulated  staff  modules.  Data  required  by  a  live  staff  module 
for  OPLAN/ORDER  preparation  can  be  obtained  in  one  of  two  ways: 

•  Current  situation  data  may  be  obtained  "on-line"  by 
queries  to  simulated  staff  modules  or  the  battle  out¬ 
come  generator,  as  appropriate. 

•  Other  data  will  be  prepared  "off-line"  in  advance  by 
the  controller  and  may  be  accessed  by  the  players  on 
request. 

A  completed  OPLAN/ORDER  (or  assigned  portions  thereof)  is  transmitted 
by  the  live  staff  module  to  the  controller  who  logs  it  in  for  later 
evaluation  of  staff  module  performance.  Such  an  OPLAN/ORDER  has  no 
direct  impact  on  the  ongoing  simulation.  The  requirement  to  perform 
such  planning  activities  does,  of  course,  impact  on  the  workload,  and 
hence  the  stress,  imposed  on  a  live  staff  module  and  thus  effect  its 
performance  in  monitoring  and  controlling  the  on-going  battle. 

If  a  completed  OPLAN/ORDER  is  to  be  evaluated  by  executing  it 
within  the  simulation,  it  can  be  introduced  by  the  controller  in  the 
same  way  that  he  would  introduce  the  special  situation  and  any  oper¬ 
ations  orders  prepared  by  players  in  advance  of  the  simulation, 
normally  by  means  of  a  preprocessor,  for  any  other  kind  of  play. 

This  will,  however,  require  that  the  on-qoing  play  be  stopped  at  some 
appropriate  juncture  in  order  to  transition  to  a  new  OPLAN/ORDER. 
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3.4.4  Other  Staff  Elements 


As  has  already  been  indicated  in  paragraph  3.4.1  above,  there 
are  many  other  staff  elements  collocated  or  closely  associated  with 
the  five  staff  modules  of  the  Blue  staff  being  simulated.  For  ex¬ 
ample,  much  of  the  detailed  management  of  the  sensor  systems  avail¬ 
able  to  the  G-2  and  the  production  of  intelligence  from  these  sources 
is  performed  at  the  All  Source  Analysis  Center  (ASAC)  which  is  part 
of  the  operations  center  of  the  CEWI  Battalion.  Similarly,  engineer 
information  processing  is  performed  by  an  engineer  element,  CBR  pro¬ 
cessing  by  a  CBRE,  Army  air  activities  by  a  DAME,  Air  Force  air  sup¬ 
port  activities  by  a  TASE,  etc.  The  decision  was  made  to  incorporate 
such  activities  into  the  battle  outcome  generator  where  they  would  be 
handled  in  the  same  way  as  subordinate  units,  i.e.,  their  activities 
would  not  be  simulated  explicitly,  but  those  of  their  outputs  and 
inputs  that  flow  across  the  five  explicitly  modeled  staff  modules 
would  be  made  explicit  as  are  orders  to  and  reports  from  subordinate 
units. 

3.4.5  Simulation  of  Command  and  Control 


The  following  question  arose  with  respect  to  the  design  of 
the  simulated  command  and  control  elements  within  the  simulation: 

•  How  can  the  simulation  of  command  and  control  actions 
within  the  simulation  (nort-populated  staff  modules, 
other  staff  elements  not  specifically  represented,  and 
subordinate  staffs)  be  carried  out  so  as  to  reflect  a 
realistic,  variable  level  of  performance  by  populated 
staff  modules? 


This  problem  is  best  explained  with  reference  to  Figure  4-1. 

As  shown  in  that  figure.  Class  1  events  occur  within  staff  modules; 

Class  2,  3,  and  4  events  occur  at  the  staff  module  boundaries;  and 
Class  5  events  occur  within  the  Battle  Outcome  Module.  The  design 
provides  that  these  events  are  to  be  connected  by  event  threads  which 
cause  the  successive  events  to  occur  in  the  prescribed  logical  sequence. 
Within  a  populated  module  the  players  themselves  carry  out  the  Class 
1  events  and  react  to  or  generate  the  interface  events.  In  a  simu¬ 
lated  module,  these  threads  must  be  provided  within  the  simulation. 

It  is  conceptually  a  simple  matter  to  close  the  event  threads  that  are 
routed  through  the  simulated  modules  so  that  they  are  essentially  in¬ 
sulated  from  any  perturbations  to  the  information  flow  that  might  oc¬ 
cur  if  a  populated  module  did  not  behave  in  the  manner  being  simulated 
when  the  module  is  not  populated.  If  the  model  were  designed  in  this 
manner,  the  only  abnormal  behavior  of  a  populated  module  that  would 
be  reflected  in  the  simulation  would  be  failure  to  close  an  event 
thread  that  led  through  that  module.  Such  a  design  would  not  be  re¬ 
sponsive  to  the  major  objective  of  providing  feedback  to  players  on 
the  results  of  their  actions.  The  simulation  should  show  the  effect 
of  degraded  performance  within  a  live  staff  module  in  all  of  the 
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other  command  control  activities  being  simulated.  This  will  require 
very  careful  and  detailed  analysis  of  all  event  thread  routing  to 
insure  that  the  effects  of  incorrect  staff  action  by  a  live  staff 
module  are,  in  fact,  portrayed  as  unforeseen  events  and  delayed  and/ 
or  degraded  reports  that  would  result.  Examples  of  such  degraded 
performance  by  a  live  G-2  module  would  be:  faulty  tasking  of  sensor 
systems  that  would  reduce  the  enemy  information  available  to  the 
command  group  or  the  G-3;  Assignment  of  an  intelligence  mission  to 
the  cavalry  squadron  without  coordination  with  G3  which  resulted  in 
non-availability  of  the  squadron  for  an  operational  mission;  or 
faulty  tasking  of  sensor  systems  that  denied  important  target  informa¬ 
tion  to  the  FSE. 

One  important  facet  of  this  problem  that  cannot  be  overlooked 
is  the  real  world  response  time  to  such  faulty  actions.  For  example, 
faulty  tasking  of  sensors  by  G2  that  resulted  in  degraded  target  in¬ 
formation  for  the  FSE  would  affect  the  on-going  battle.  Faulty  sen¬ 
sor  tasking  that  reduced  intelligence  available  to  the  G3  or  the  com¬ 
mand  group  could  affect  the  on-going  battle,  but  would  even  more 
likely  lead  to  bad  planning  for  tomorrow's  battle.  The  latter  ef¬ 
fect  is  difficult  to  capture  in  a  4-12  hour  scenario.  Thus,  the  ef¬ 
fects  of  faulty  staff  actions  that  lead  to  degraded  planning  for 
future  action  may  be  difficult  to  capture  without  implementing  the 
faulty  plan. 

This  problem  has  not  been  resolved  in  the  current  effort  and 
additional  design  effort  will  be  needed  before  a  simulation  can  be 
built  that  will  implement  this  design  objective. 

3.4.6  Task  Design  for  Interactive  Simulations- 

Another  question  arose  with  respect  to  populated,  i.e.,  in¬ 
teractive,  staff  modules: 

0  How  should  the  tasks  within  a  populated  staff  module  be 
designed  or  redesigned  so  as  to  emphasize  those  tasks 
which  are  the  subject  of  investigation,  deemphasize 
those  which  might  only  increase  player  boredom  and  de¬ 
crease  his  interest,  and  do  this  in  a  manner  which  re¬ 
tains  realism  and  credibility? 

This  problem  arises  from  the  following  consideration.  If  the 
simulation  is  to  be  a  cost-effective  tool  for  research,  not  only  must 
the  personnel  requirements  be  held  to  a  minimum  in  the  control  sec¬ 
tion,  but  the  number  of  players  in  a  live  staff  module  must  also  be 
held  to  a  credible  minimum.  One  way  to  approach  this  goal  is  to 
eliminate  some  of  the  low  skill  level,  high  frequency,  and  hence, 
boring  tasks  within  the  staff  module.  An  insight  as  to  what  this  en¬ 
tails  may  be  gained  by  viewing  the  staff  module  as  a  decision  node 
and  looking  at  the  sequence  of  kinds  of  processes  that  it  performs. 
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Figure  3-7  is  a  representation  of  a  series  of  processes  such 
as  a  decision  node  carries  out  on  information  flowing  through  the 
node.  At  the  bottom  of  the  figure  is  an  external  information  stream — 
the  communications  network— which  the  node  taps  and  to  which  it  con¬ 
tributes.  Six  progressively  more  complex  processing  levels  are  de¬ 
picted.  The  information  that  flows  up  from  the  external  stream  must 
first  be  received,  a  Level  I  or  communications  process.  The  received 
information  in  a  tactical  military  system  is  in  the  form  of  orders 
(plans),  summaries,  reports,  queries,  or  requests.  These  must  be 
tagged,  sorted,  recorded  (think  of  the  large  number  of  telephone  and 
voice  radio  inputs),  and  used  to  update  files;  much  of  it  is  also 
displayed  on  situation  maps  or  "totes."  The  composite  of  these 
processes  may  be  called  Level  II  or  message  center  and  filing  pro¬ 
cesses.  The  Level  II  processes  produce  a  data  base,  some  part  of 
which  is  in  the  form  of  visible  displays  for  ready  reference.  It  is 
pertinent  to  comment  in  passing  that  the  graphical  representation  of 
certain  kinds  of  information  on' a  situation  map  is  the  substitute  for 
the  hill  overlooking  the  battlefield  and  for  helicopters  when  the 
latter  cannot  fly  or  see. 

The  next  four  process  levels  use  the  files  in  successively 
more  complex  ways.  Note  that  they,  too,  update  the  files,  but  these 
updates  are  more  in  the  nature  of  manipulations  on  the  basic  data 
added  by  Level  II.  These  utilization  processes  begin  with  Level  III, 
selective  retrieval  of  information  from  the  files.  At  Level  IV,  such 
data  are  aggregated  by  means  of  a  priori  rules,  which  may  vary  from 
simple  arithmetic  combinations  to  more  sophisticated  rules  of  combina¬ 
tion  such  as  the  appearance  of  three  or  four  maneuver  battalions  op¬ 
erating  in  the  same  area  triggers  the  search  for  their  associated 
fire  and  service  support  elements.  The  important  consideration  is 
that  the  rules  for  aggregation  have  been  determined  in  advance  and 
are  stored.  Process  Level  V  also  aggregates  data,  but  the  rules 
for  aggregation  are  devised  by  the  user  in  real  time— that  is,  he 
hypothesizes,  through  pattern  recognition,  new  and  higher  level  in¬ 
terpretations  of  the  data  being  presented.  For  example,  the  rapid 
increase  in  density  of  artillery  in  a  given  sector  is  interpreted  as 
an  indicator  of  enemy  intent  to  attempt  a  breakthrough  in  that  sector. 
Process  Level  5  may  also  be  accomplished  in  a  succession  of  stages 
that  amounts  to  piling  hypotheses  one  on  top  of  another.  Furthermore, 
data  aggregations  may  be  extrapolated  forward  in  time.  This  amounts 
to  yet  another  hypothesis  formulation  of  a  different  type;  assumptions 
are  made  about  observed  rates  and/or  accelerations.  For  example, 
examination  of  present  positions  and  rates  of  advance  for  both  sides 
leads  to  a  prediction  that  the  main  battle  will  occur  at  point  Y  at 
time  T.  Level  V  produces  what  is  commonly  called  "perception."  At 
the  highest  level,  Level  VI,  data  aggregations  are  compared  and 
evaluated,  and  one  or  more  are  selected.  This  last  is  the  culmina¬ 
tion  of  the  decision  process. 


* 
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Implementation  of  the  decision  requires  composing  a  decision 
node  output  that  will  be  in  one  of  the  same  forms  as  were  the  inputs. 
The  more  complex  of  these  outputs  can  involve  further  utilization  of 
the  data  base  at  Levels  III  through  V  as  indicated.  This  implies 
that  the  basic  decision  acts  like  a  new  system  input  that  triggers 
additional  subordinate  decisions  necessary  for  the  implementation  of 
the  basic  decision.  As  the  arrows  show,  there  may  therefore  be 
reiterative  cycling  through  the  data  base  to  complete  the  composition 
of  the  staff  output  that  implements  the  basic  decision.  It  will  be 
noted  that  this  view  of  the  command  and  staff  processing  of  informa¬ 
tion  is  essentially  the  same  as  that  presented  in  Chapter  5  of  FM 
101-51  and  is  just  another  way  of  looking  at  the  functional  flow  chart 
of  the  commander's  information  flow  and  decision  processes.  Note 
too  that  every  output  from  the  node  involves  some  processing  at  Level 
VI.  This  may  be  as  simple  as  a  decision  to  relay  an  incoming  message 
to  a  new  addressee,  which  says  that  almost  every  process  at  every 
level  has  been  a  one-for-one  transformation  except  for  the  selection 
of  one  or  more  new  addressees  for  an  incoming  message. 

With  this  view  of  a  manual  information  processing  system,  we 
can  gain  some  insights  as  to  what  might  happen  when  we,  in  effect, 
shift  the  interface  between  the  staff  module  and  the  outside  world 
from  its  peripheral  communication  nodes  and  move  some  of  the  lower 
level  communication  and  message  center  and  filing  functions  out  of  the 
module  and  into  the  simulation.  We  are  now  faced  with  the  problem  of 
redefining  the  tasks  to  be  conducted  within  the  staff  module  in  such 
a  way  that  the  node  remains  a  realistic,  credible,  military  decision¬ 
making  environment,  i.e.,  appears  to  the  players  to  be  a  staff  ele¬ 
ment  and  not  a  laboratory  for  studying  human  reactions.  The  problem 
is  quite  similar  to  that  faced  by  the  ADP  assisted  system  designer 
becaust  it  amounts  to  shifting  the  interface  between  the  decision 
maker  and  the  outside  world  (see  also  paragraph  3.4.7  below). 

This  problem,  too,  can  use  additional  design  effort  in  order 
to  assure  that  the  simulation,  when  built,  has  maximum  utility  as  a 
research  tool . 

3.4.7  ADP  Assisted  Staff 


Paragraph  2.4.5  has  already  pointed  out  that  providing  ADP 
assistance  to  the  staff  substantially  complicates  the  information 
flow.  Not  only  must  computer  terminals  be  added  to  the  populated 
staff  modules,  but  the  simulation  data  base  must  be  expanded  to 
provide  information  to  players  in  different  formats  and  aggregated 
differently.  For  example,  much  information  provided  players  on  a 
spot  report  basis  in  the  manual  mode  is  replaced  by  access  to  a 

1U . S .  Department  of the  Army ,  Staff  Organization  and  Procedure,  FM 
101-5,  Washington,  July  1972. 
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special  data  base  that  is  updated  as  a  result  of  simulated  events  to 
reflect  the  current  status  of  the  forces  being  managed.  Such  a  capa¬ 
bility  adds  a  new  class  of  events  to  the  simulation  which  is  defined 
in  Paragraph  4.1.  In  order  to  have  maximum  usefulness,  the  simula¬ 
tion  should  also  be  able  to  reflect  the  effects  of  making  adaptive 
software  available  to  players,  thus  permitting  players  to  make  changes 
in  the  amount,  kind,  reporting  frequency,  and  the  format  of  the  dis¬ 
played  information.  In  order  to  keep  the  problem  reasonably  tractable 
and  also  within  anticipated  budget  constraints,  the  initial  imple¬ 
mentation  of  the  model  will  be  a  simulation  of  manual  data  exchanges 
between  players  and  the  simulation.  The  basic  design,  as  will  be 
discussed  in  Section  4,  will  permit  the  addition  of  an  ADP-assisted 
staff  capability  as  an  increment  at  a  later  time. 

3.4.8  Initial  Configurations 

Another  design  consideration  that  needed  attention  was  the 
question  of  the  number  of  staff  modules  that  could  be  populated 
simultaneously.  Although  the  original  design  concept  included  all 
possible  combinations  from  zero  to  six  (including  the  Red  player 
module),  it  soom  became  apparent  that  handling  a  significant  number 
of  live  modules  simultaneously  would  require  a  substantial  personnel 
complement  within  Control.  More  than  one  or  two  personnel  within 
Control  would  make  running  the  model  prohibitively  expensive  and 
there  is  no  immediate  requirement  to  handle  more  than  two  populated 
staff  modules  at  one  time.  It  was  therefore  decided  that  the  initial 
implementation  would  be  limited  to  not  more  than  two  populated  staff 
modules.  The  expansion  of  this  capability  to  permit  other  and  larger 
configurations  will  be  considered  at  a  later  time  after  experience 
is  acquired  in  the  actual  loadings  that  will  be  imposed  on  Control. 

It  is  also  likely  that  the  provision  of  ADP  assistance  to  staff 
modules  will  reduce  the  requirement  for  Controller  intervention  in 
the  data  flow.  This  is  discussed  in  more  detail  in  Paragraph  4.4. 
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Section  4 
TOP-DOWN  DESIGN 

This  section  presents,  first,  the  general  design  concept,  for 
the  integrated  division-level  battle  simulation,  and  second,  the  basic 
elements  of  the  proposed  initial  implementation.  The  initial  implemen¬ 
tation  will  be  subject  to  the  following  specific  constraints  on  the 
scope  of  the  full  concept: 

•  One  or  two  human  controllers,  aided  by  computerized 
preprocessing  capabilities  and  an  interactive  executive 
control  routine,  will  control  the  play  of  the  game. 

•  Configurations  of  play  will  be  limited  to  no  more  than 
two  populated  staff  modules  (any  two  out  of  six  modules). 

•  Blue  staff  modules  will  operate  under  a  manual  staff 
system  only. 

The  section  begins  with  the  fundamental  structure  of  the  design  concept. 
This  structure  is  followed  by  the  specification  of  the  proposed  physi¬ 
cal  layout,  computer  capabilities,  and  controller  functions  required 
for  the  initial  implementation.  The  basic  elements  of  the  implemen¬ 
tation  and  the  proposed  general  approach  for  attaining  them  are  then 
described.  The  section  concludes  with  two  subsections:  one  demonstrat¬ 
ing  the  manner  in  which  the  first  implementation  provides  a  framework 
capable  of  extensions  and  augmentations  beyond  the  constraints  shown 
above  and  the  other  providing  insight  as  to  the  applicability  of  the 
simulation  for  behavioral  science  research,  evaluation  of  doctrine  and 
tactics,  and  training  of  the  division  command  groups/staff. 

4.1  DESIGN  CONCEPT 

The  fundamental  design  concept  of  the  integrated  division-level 
battle  simulation  is  that  of  an  event-store  simulator  in  which  the  simu¬ 
lated  time  clock  is  geared  to  a  real  clock  so  that  the  simulated  combat 
may  be  played  in  slow  time,  real  time,  or  fast  time.  The  basic  structure 
of  the  system  as  depicted  in  Figure  2-6  consists  of  seven  functional 
"boxes"  or  simulation  modules  in  which  command  and  staff  operations  and 
the  resulting  division-level  combat  are  simulated  by  the  dynamic  portrayal 
of  the  occurrence  of  significant  events  in  the  battle.  The  structure 
handled  five  classes  of  such  events,  as  follows: 

•  Class  1  -  Staff  processing  events. 

•  Class  2  -  Exchange  of  tactical  information  between  staff 
elements . 
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Class  3  -  Tactical  information  outputs  from  staff  elements 
Class  4  -  Tactical  information  inputs  to  staff  elements. 
Class  5  -  All  other  events  in  the  battle  simulation. 


t 

The  seven  modules,  and  the  places  where  the  five  event  classes  fitted 
into  the  conceptual  structure,  are  shown  in  Figure  4-1. 

Subsequent  to  presentation  of  the  original  concept  the  basic 
structure  has  been  further  defined  to  reflect  the  following  additional 
components: 

•  An  additional  functional  module  -  a  module  which  simu¬ 
lates  higher  headquarters,  adjacent  division  headquarters. 
Blue  staff  elements  not  delineated  by  the  boxes  on  the 
left,  and  "acts  of  God"  events. 

•  An  additional  defined  event  class  -  Class  6  events  which 
are  interface  events  between  staff  elements  and  their 
ADP  terminal  devices. 

•  The  controller's  role  in  the  simulation. 

The  modified  conceptual  structure  is  shown  in  Figure  4-2. 

4.1.1  Configurations 

In  the  basic  concept  shown  in  the  two  figures,  the  five  Blue 
staff  modules  on  the  left  and  the  single  Red  command  module  on  the 
right  may  consist  of  either  a  group  of  human  players  executing  standard 
staff  procedures  or  else  a  set  of  simulation  rules  or  algorithms  for 
processing  the  Class  1  and  Class  6  events  inherent  in  the  staff  proce¬ 
dures.  The  choice  between  the  populated  version  of  these  modules  or 
the  simulated  version  depends  on  the  application. 

Since  the  simulation  rules  or  algorithms  throughout  the  struc¬ 
ture  will  always  depend  on  the  choice  of  configuration  being  played, 
that  is,  the  combination  of  populated  modules  and  simulated  modules  in 
the  game,  the  configuration  number  has  been  defined  as  a  basic  control 
variable  in  the  system.  The  definition  is  embodied  in  Table  4-1. 

Configuration  number  is  an  integer  with  a  value  zero  to  63. 

The  binary  representation  of  confi guration  number  delineates  the  popu¬ 
lated  modules  and  simulated  modules  selected  for  play.  The  control 
variable  itself  must  be  incorporated  into  the  basic  logic  of  all  simu¬ 
lation  rules  in  order  to  assure  that  the  proper  internal  and  external 
routing  of  tactical  information  messages  is  preserved. 

It  should  be  noted  that  the  basic  design  concept,  with  its  64 
alternative  configurations,  reflects  a  fundamental  asymmetry  with 


Figure  4-1.  Basic  Modules  of  the  Integrated  Division-Level  Battle 
Simulation,  Showing  the  Five  Classes  of  Events. 


Figure  4-2.  Modified  Version  of  the  Integrated  Division-Level  Battle 
Simulation  Showing  the  Six  Classes  of  Events. 


Table  4-1.  Configuration  Number 


CONFIGURATION 

NUMBER 

BINARY 

REPRESENTATION 

NUMBER  OF 
POPULATED  MODULES 

IDENTIFICATION  OF 

POPULATED  MODULES 

0 

000000 

0 

(none) 

1 

000001 

1 

BLUE  CG 

2 

000010 

1 

BLUE  FSE 

3 

000011 

2 

BLUE  CG  and  FSE 

4 

000100 

1 

BLUE  G2 

5 

000101 

2 

BLUE  CG  and  G2 

6 

000110 

2 

BLUE  FSE  and  G2 

7 

000111 

3 

BLUE  CG,  FSE,  and  G2 

8 

001000 

1 

BLUE  G3 

9 

001001 

2 

BLUE  CG  and  G3 

10 

001010 

2 

BLUE  FSE  and  G3 

11 

001011 

3 

BLUE  CG,  FSE,  and  G3 

12 

001100 

2 

BLUE  G2  and  G3 

13 

001101 

3 

BLUE  CG,  G2  and  G3 

14 

ooi i io 

3 

BLUE  FSE,  G2  and  G3 

15 

001111 

4 

BLUE  CG,  FSE,  G2,  and  G3 

16 

010000 

1 

BLUE  G1/G4 

17 

010001 

2 

BLUE  CG  and  G1/G4 

18 

010010 

2 

BLUE  FSE  and  G1/G4 

19 

010011 

3 

BLUE  CG,  FSE,  and  G1/G4 

20 

010100 

2 

BLUE  G2  and  G1/G4 

21 

010101 

3 

BLUE  CG,  G2,  and  G1/G4 

22 

010110 

3 

BLUE  FSE,  G2,  and  G1/G4 

23 

010111 

4 

BLUE  CG,  FSE,  G2,  and  G1/G4 

24 

011000 

2 

BLUE  G3  and  G1/G4 

25 

011001 

3 

BLUE  CG,  G3,  and  G1/G4 

26 

011010 

3 

BLUE  FSE,  G3,  and  G1/G4 

27 

011011 

4 

BLUE  CG,  FSE,  G3  and  G1/G4 

28 

011100 

3 

BLUE  G2,  G3,  and  G1/G4 

29 

011101 

4 

BLUE  CG,  G2,  G3,  and  G1/G4 

30 

011110 

4 

BLUE  FSE,  G2,  G3,  and  G1/G4 

31 

011111 

5 

BLUE  CG,  FSE,  G2,  G3,  and 
G1/G4 

32 

100000 

1 

RED  CMD  only 

33 

100001 

2 

BLUE  CG  vs  RED  CMD 

34 

100010 

2 

BLUE  FSE  vs  RED  CMD 

35 

100011 

3 

BLUE  CG,  FSE  vs  RED  CMD 

36 

100100 

2 

BLUE  G2  vs  RED  CMD 

37 

100101 

3 

BLUE  CG,  G2,  vs  RED  CMD 

38 

100110 

3 

BLUE  FSE,  G2  vs  RED  CMD 

39 

loom 

4 

BLUE  CG,  FSE,  G2  vs  RED  CMD 

40 

101000 

2 

BLUE  G3  vs  RED  CMD 

41 

101001 

3 

BLUE  CG,  G3  vs  RED  CMD 

42 

101010 

3 

BLUE  FSE,  G3  vs  RED  CMD 

Table  4-1.  Configuration  Number  (continued) 


CONFIGURATION 

NUMBER 

BINARY 

REPRESENTATION 

NUMBER  OF 
POPULATED  MODULES 

IDENTIFICATION  OF 

POPULATED  MODULES 

43 

101011 

4 

BLUE  CG,  FSE,  G3  vs  RED  CMD 

44 

101100 

3 

BLUE  G2,  G3  vs  RED  CMD 

45 

101101 

4 

BLUE  CG,  G2,  G3  vs  RED  CMD 

46 

101110 

4 

BLUE  FSE,  G2,  G3  vs  RED  CMD 

47 

101111 

5 

BLUE  CG,  FSE,  G2,  G3  vs 

RED  CMD 

48 

110000 

2 

BLUE  G1/G4  vs  RED  CMD 

49 

110001 

3 

BLUE  CG,  G1/G4  vs  RED  CMD 

50 

110010 

3 

BLUE  FSE,  G1/G4  vs  RED  CMD 

51 

noon 

4 

BLUE  CG,  FSE,  G1/G4  vs 

RED  CMD 

52 

110100 

3 

BLUE  G2 ,  G1/G4  vs  RED  CMD 

53 

110101 

4 

BLUE  CG,  G2,  G1/G4  vs  RED 
CMD 

54 

110110 

4 

BLUE  FSE,  G2,  G1/G4  vs  RED 
CMD 

55 

110111 

5 

BLUE  CG,  FSE,  G2,  G1/G4  vs 
RED  CMD 

56 

111000 

3 

BLUE  G3,  G1/G4  vs  RED  CMD 

57 

111001 

4 

BLUE  CG,  G3,  G1/G4  vs  RED 
CMD 

58 

111010 

4 

BLUE  FSE,  G3,  G1/G4  vs  RED 
CMD 

59 

moil 

5 

BLUE  CG,  FSE,  G3,  G1/G4  vs 
RED  CMD 

60 

111100 

4 

BLUE  G2 ,  G3,  G1/G4  vs  RED 
CMD 

61 

111101 

5 

BLUE  CG,  G2 ,  G3,  G1/G4  vs 
RED  CMD 

62 

111110 

5 

BLUE  FSE,  G2 ,  G3,  G1/G4  vs 
RED  CMD 

BLUE  CG,  FSE,  G2,  G3,  G1/G4 
vs  RrD  CMD 
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respect  to  the  Blue  and  Red  sides  in  the  play  of  division-level  combat. 
The  Blue  side  will  always  consist  of  the  division  command  group  and 
principal  staff  sections,  whether  the  individual  staff  elements  are 
populated  modules  or  simply  simulated  modules.  The  Red  side,  on  the 
other  hand,  will  consist  of  only  the  Red  commander  himself  (with  possi¬ 
bly  an  assistant).  The  Red  Command  Module  will  always  present  the 
commander  with  "completely  staffed"  alternatives  for  decision.  He  will 
execute  his  command  functions  without  further  assistance  from  staff 
elements . 

4.1.2  Classes  of  Events 


The  different  classes  of  events  associated  with  the  basic  design 
concept  are  shown  in  Figure  4-2  by  the  open-faced  arrows  with  the  class 
numbers  inside.  The  Class  1  events  (staff  processing)  and  the  Class  6 
events  (staff  interfacing  with  their  field  ADP  terminals)  are  shown  in¬ 
side  the  five  Blue  Staff  Modules  and  inside  the  single  Red  Command 
Module.  The  Class  2  events  (staff  coordination  between  staff  sections) 
are  shown  interconnecting  the  five  Blue  Staff  Modules.  The  Class  3 
events  (frag  orders  to  subordinate  units,  reports  to  higher  headquarters, 
and  other  staff  outputs)  are  shown  emanating  from  the  staff  modules  and 
pointing  into  the  interior  modules  of  the  simulation:  the  battle  out¬ 
come  generator  (BOG)  and  the  other  units  module.  The  Class  4  events 
(staff  inputs;  reports  from  the  BOG  or  the  other  units  module)  are  shown 
with  arrow  heads  reversed  from  those  of  Class  3.  Finally  the  Class  5 
events  (battle  events  and  events  stemming  from  other  units)  are  shown 
wholly  inside  the  interior  modules  of  the  simulation. 

All  events  represent  significant  occurrences  in  the  division- 
level  combat,  but  Class  2,  Class  3,  Class  4,  and  Class  6  events  are 
further  qualified  as  "interface"  events  because  they  deal  exclusively 
with  tactical  information  flow.  It  will  be  shown  below  that  the  defini¬ 
tion  and  numbering  of  interface  events  will  always  be  associated  with 
the  specific  tactical  information  messages  or  documents  identified  in 
Design  Note  A. 

The  position  of  the  human  controller(s)  in  the  basic  design 
concept  is  shown  in  Figure  4-2.  As  it  relates  to  simulation  events, 
this  position  suggests  some  controller  involvement  with  the  imposition 
of  certain  decision  choices,  intervention  with  military  judgement,  and 
the  handling  of  staff  input/output.  The  controller’s  station  shown  in 
the  middle  of  the  simulation,  therefore,  implies  the  following  two 
design  imperatives: 

•  One  or  more  human  controllers  will  always  be  required 
to  run  the  game. 

•  The  controllers  will  have  to  perform  their  functions 
according  to  the  schedule  of  events  and  the  simulated 
time  clock. 
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A  detailed  specification  of  the  controller's  functions  depends  on  the 
level  of  computer  assistance  used  to  implement  the  simulation  and  on 
the  actual  procedures  followed  in  playing  populated  staff  modules.  This 
specification  is  given  in  paragraph  4.2.2  for  the  initial  implementation 

Under  any  proposed  implementation,  however,  there  will  always  be 
certain  Class  1  events  and  Class  5  events  in  which  the  control ler(s) 
must  intervene  in  order  to  supplement  the  logical  rules  of  the  simula¬ 
tion  or  to  influence  the  onslaught  of  events  on  a  populated  staff  module 
These  Class  1  or  Class  5  events  are  therefore  further  qualified  as 
"release"  events,  because  the  control ler(s )  must  execute  their  "release, 
that  is,  complete  the  intervention  on  or  before  the  time  of  occurrence 
as  measured  by  the  simulated  clock.  The  specific  release  events  in  the 
initial  implementation  and  the  method  provided  for  controller  interven¬ 
tion  are  discussed  further  in  paragraph  4.3.6. 

The  remainder  of  this  subsection  provides  the  definitions  and 
detailed  descriptions  of  the  events  in  each  class  that  have  been  iden¬ 
tified  for  the  simulation. 

At  the  beginning  of  the  basic  design  effort,  an  event  numbering 
convention  was  adopted  to  provide  a  basis  for  organizing  the  large  num¬ 
ber  of  events  anticipated  to  emerge  in  each  class.  The  convention  is 
shown  in  Table  4-2. 


Table  4-2.  Event  Numbering  Convention  Used  in  the  Basic  Design. 


Class 

T 

Events 

are 

numbered 

100 

to 

199. 

Class 

2 

Events 

are 

numbered 

200 

to 

299. 

Class 

3 

Events 

are 

numbered 

300 

to 

399. 

Class 

4 

Events 

are 

numbered 

400 

to 

499. 

Class 

5 

Events 

are 

numbered 

500 

to 

599. 

Class 

6 

Events 

are 

numbe red 

600 

to 

699. 

It  can  be  seen  from  the  table  that  the  convention  is  based  on 
the  a  priori  assumption  that  the  design  will  involve  no  more  than  100 
defined  events  in  each  of  the  six  classes.  In  the  material  that  follows 
only  a  subset  of  the  hundred  numbers  have  resulted  in  basic  event  defi¬ 
nitions.  Furthermore,  beginning  with  the  Class  2  events,  the  interface 
events  will  exhibit  event  numbers  that  are  directly  related  to  the 
standardized  tactical  messages. 
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4. 1.2.1  Staff  Processing  Events 

Class  1  events  are  the  action-handling  steps  performed  by  indi¬ 
vidual  members  of  a  staff  section  in  completing  a  required  staff  action. 
For  every  input/output  relationship  prescribed  for  the  staff  element 
(see  Design  Note  C),  there  will  be  a  standard  operating  procedure  (SOP) 
spelling  out  the  action  steps  required.  These  steps  will  be  executed 
whenever  the  staff  element  is  triggered  to  perform  the  staff  action. 

If  the  staff  section  is  a  populated  staff  module,  the  action 
steps  will  be  executed  entirely  by  the  human  players.  The  simulation 
itself  will  acknowledge  the  completion  of  the  staff  action  only  by  means 
of  the  interface  events  (staff  outputs)  stemming  from  the  action;  it 
will  not  record  the  occurrence  of  individual  action  steps  nor  measure 
the  performance  of  the  players  regarding  conformance  to  the  action  SOP. 
The  performance  measurements  on  human  players  will  be  handled  ir>  a  sep¬ 
arate  manner,  as  discussed  in  Section  5. 

Class  1  events  have  meaning  only  for  those  staff  sections  that 
are  simulated  staff  modules.  Under  all  configurations  of  play  except 
one  (confi guration  "63"  in  Table  4-1),  one  or  more  staff  modules  will 
always  be  simulated  in  order  to  provide  the  full  division  staff  envir¬ 
onment  required  for  a  single  populated  staff  module. 

For  simulated  staff  modules  operating  under  a  manual  staff  sys¬ 
tem,  the  action  steps  in  each  staff  action  will  consist  of,  and  be 
represented  by,  a  thread  of  Class  1  events.  All  such  event  threads  will 
contain  an  internal  trigger,  or  starting,  Class  1  event,  and  one  or 
more  terminating,  or  ending,  Class  1  events.  The  number  of  events  sim¬ 
ulated  between  the  trigger  and  the  terminating  action  steps  will  depend 
on  the  individual  action  SOPs  and  on  the  level  of  detail  used  in  simu¬ 
lating  the  staff  action. 

The  event  numbers  and  definitions  of  the  Class  1  events  that  re¬ 
present  the  internal  triggers  and  the  terminators  of  all  staff  actions 
are  presented  in  Table  4-3.  Class  1  events  are  specified  further  in 
Design  Note  I  and  the  internal  triggers  and  terminations  are  defined  in 
Design  Note  J.  Included  in  the  Design  Note  I  material  is  a  discussion 
of  two  areas  that  require  further  research  to  improve  the  efficiency  of 
the  simulation. 

The  simulation  will  provide  basic  rules  or  algorithms  that  will 
generate  the  interval  of  simulated  time  taken  to  complete  staff  actions. 
This  interval  will  be  a  function  of  the  level  of  action  traffic  imping¬ 
ing  on  the  staff  section  as  well  as  the  number  of  action  steps  in  the 
staff  actions. 

Some  staff  actions  will  contain  intermediate  Class  1  events  that 
are  release  events,  that  is,  events  which  require  controller  interven¬ 
tion  as  described  above.  For  example,  in  an  exercise  with  a  populated 
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Table  4-3.  Class  1  Events. 


Event  Number  Definition  of  the  Event _ 

Internal 
Tri qgers 

100  Clock  indicates' that  is  is  time  to  initiate  staff  action. 

101  Receives  a  tactical  information  message  from  BOG  or  higher  HQ. 

102  Receives  a  retransmitted  copy  of  input  to  another  section. 

103  Receives  an  info  copy  of  output  by  another  section. 

104  Receives  a  query  from  another  section. 

105  Receives  a  request  for  concurrence2  from  another  section. 

10b  Receives  a  request  for  consideration^  from  another  section. 

107  Receives  a  concurring  response  to  a  request  for  concurrence. 

108  Receives  a  non-concurring  response  to  a  request  for  concurrence. 

109  Receives  an  info  copy  of  a  request  frag  order. 

110  Receives  a  non-concurring  response  to  a  request  for  consideration. 

111  Receives  a  response  to  its  query  to  another  section. 

112  Receives  information  from  another  section. 

Action 

Steps 

(Not  yet  defined. )  ' 


Terminators 

189  -Sends  to  selected  staff  elements. 

190  Issues  frag  order  or  warning  order. 

191  Initiates  query*. 

192  Initiates  a  request  for  concurrence2. 

193  Initiates  a  request  for  consideration^. 

194  Initiates  a  report  for  higher  headquarters. 

195  Aggregates  its  information  on  file  for  a  response. 

196  Issues  a  concurring  response  to  a  request  for  concurrence. 

197  Issues  a  non-concurring  response  to  a  request  for  concurrence. 

198  Issues  a  non-concurring  response  to  a  request. 

199  Retransmits  copies  of  its  input. 


For  all  staff  modules  except  Blue  CG,  queries  will  be  automatically 
separated  into  staff  queries  or  queries  to  subordinate  units.  The 
Blue  CG  module  will  have  the  selectable  option  between  staff  queries 

or  queries  to  subordinate  units, 
o 

A  request  for  concurrence  is  based  on  a  frag  order  under  initiator's 
purview. 

2 

A  request  for  consideration  is  based  on  a  frag  order  under  recipient's 
purview. _ _____ _ 
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G2  staff  module  and  a  simulated  G3  module,  the  G2  player(s)  might  submit 
a  request  for  concurrence  to  G3  regarding  a  Frag  Order  (Intel).  The 
release  event  would  occur  following  the  trigger  (Event  No.  105  in  Table 
4-3)  in  the  simulated  G3  module.  On  or  before  the  time  of  occurrence, 
the  controller  would  have  to  insert  the  decision  to  reflect  the  choice 
of  the  alternative  responses  by  the  G3  (Event  Nos.  196  or  197  in  Table 
4-3). 

4. 1.2. 2  Staff  Coordination  Events 

Class  2  events  are  interface  events  covering  the  exchange  of 
tactical  information  between  staff  sections.  The  internal  routing  re¬ 
quirements  of  all  staff  actions,  staff  queries,  requests,  and  responses 
will  be  effected  through  Class  2  events. 

In  accordance  with  the  fundamental  asymmetry  of  the  basic  design. 
Class  2  events  will  be  used  at  the  interfaces  between  Blue  Staff  Modules 
only;  no  Class  2  events  will  occur  with  respect  to  the  single  Red  Com¬ 
mand  Module.  The  Red  side,  whether  it  is  a  populated  module  or  a  sim¬ 
ulated  module,  will  always  deal  with  completely  staffed  tacticl  deci¬ 
sion  alternatives  and  will  not  be  concerned  further  with  staff  coodina- 
tion. 


Staff  coordination  exchanges  on  the  Blue  side,  on  the  other  hand, 
can  occur  in  four  different  ways,  depending  on  the  combination  of  popu¬ 
lated  modules  and  simulated  modules  being  played.  The  four  alternative 
kinds  are  as  follows: 

•  The  initiator  of  the  exchange  is  a  live  module;  the 
recipient  is  a  simulated  module. 

t  The  initiator  is  a  simulated  module;  the  recipient  is 
a  live  modu 1 e . 

•  Both  the  initiator  section  and  the  receiving  staff  ele¬ 
ment  are  simulated  modules. 

t  The  initiator  and  the  recipient  are  both  populated  modules. 
Class  2  events  are  defined  for  all  four  cases. 

If  the  initiator  of  the  exchange  is  a  populated  module  (as  in 
items  1  and  4  above),  then  the  Class  2  event  will  be  initiated  by  a 
pencil  copy  or  typewritten  copy  of  the  exchange  prepared  by  the  human 
players,  transmitted  by  the  controller/computer,  and  then  printed  as  a 
machine  prepared  message.  Oral  exchanges  will  not  be  permitted. 

If  the  recipient  of  the  exchange  is  a  populated  module  (as  in 
items  2  and  4),  then  the  human  players  in  the  module  will  receive  the 
Class  2  message  from  the  controller/computer.  The  coordination  exchange 
will  always  appear  as  a  machine  prepared  message  to  the  human  recipients. 
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The  times  of  occurrence  and  the  tactical  information  message  of 
all  Class  2  events  regardless  of  the  cases  above,  will  always  be  recorded 
and  logged  by  the  simulation  in  order  to  provide  a  basis  for  post  pro¬ 
cessing  analysis  of  the  staff  coordination  exchanges. 

The  event  numbers  and  definitions  of  the  Class  2  events  are 
shown  in  Table  4-4.  The  table  specifies  65  different  events  numbered 
according  to  the  numbering  convention  cited  above.  The  last  two  digits 
of  the  event  numbers  are  the  embedded  reference  numbers  for  the  stand¬ 
ardized  tactical  information  messages  whose  simulated  flow  will  be  one 
of  the  central  features  of  the  basic  design.  The  message  reference 
numbers  will  be  seen  to  occur  in  one  or  more  of  the  remaining  interface 
event  classes.  They  stem  from  Design  Note  A:  The  list  of  Individual 
Tactical  Information  Messages. 

Class  2  events  are  further  specified  with  respect  to  the  manner 
they  will  be  handled  in  Design  Notes  G  and  J.  Design  Note  G  gives  the 
logical  rules  for  Class  2  events.  Design  Note  J  contain  the  event  thread 
charts  showing  the  progenitors  and  follow-on  events  associated  with  the 
staff  coordination  exchanges. 

4. 1.2. 3  Staff  Output  Events 

Class  3  events  are  the  frag  orders,  warning  orders,  and  queries 
sent  out  by  the  staff  modules  to  subordinate  units  in  the  field  as  well 
as  the  periodic  reports  and  requests  submitted  by  the  staff  sections  to 
higher  and  adjacent  headquarters.  These  staff  output  events  are  all 
interface  events  dealing  exclusively  with  tactical  information  flow  and 
corresponding  to  the  staff  output  messages  listed  in  Design  Note  A. 

Staff  outputs,  like  other  interface  events,  will  consist  of  two 
kinds  of  tactical  messages  in  the  basic  design.  The  first  type  message 
will  be  one  containing  basic  decision  variables  affecting  the  simulated 
corrtbat.  This  type  will  always  trigger  one  or  more  battle  events  (Class 
5)  so  that  the  course  of  the  simulated  conflict  will  change  in  response 
to  the  frag  orders  issued  by  the  staff  sections. 

The  second  type  of  staff  output  will  consist  of  the  required 
reports  to  Corps  or  adjacent  divisions  such  as  Preplanned  Requests  for 
Fire  Support,  the  Division  Intsum,  Division  Sitrep,  and  Division  Per¬ 
sonnel  Daily  Summary.  These  reports  represent  outputs  stemming  from 
required  actions  on  the  part  of  the  different  staff  sections,  but  hav¬ 
ing  no  direct  bearing  on  the  simulated  combat  events  in  the  BOG  within 
the  running  time  of  a  given  simulation. 

It  will  be  seen  that  the  distinction  between  the  two  kinds  of 
staff  outputs  is  preserved  in  the  proposed  implementation  of  the  design. 
The  decision  variables  will  be  incorporated  into  the  simulation  rules 
associated  with  battle  events  in  the  BOG.  The  tactical  documents  not 
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Table  4-4.  Class  2  Events. 


Event  Number _ Definition  of  Event _ 

Initiated  by  Command  Group 

201  Query  to  principal  staff  section. 

202  Info  copy:  Nuclear  Release  Request. 

203  Mission  Analysis 

204  Commander's  Guidance 

205  Commander's  Decision 

Initiated  by  Fire  Support  Element 

210  Query  to  another  staff  section. 

212  Info  copy:  Frag  Order  (FS) 

213  Info  copy:  Immediate  Request  to  Corps  for  Fire  Support. 

214  Info  copy:  Preplanned  Request  to  Corps  for  Fire  Support. 

215  Rexmttd  copy:  Arty  Sitrep. 

216  Rexmttd  copy:  Arty  Target  List 

217  Rexmttd  copy:  Friendly  Unit  Fire  Support  Capability. 

218  Rexmttd  copy:  Enemy  Unit  Fire  Support  Capability. 

219  Post  Strike  Analysis 

220  Fire  Support  Annex 

221  Staff  Request  to  another  section. 

222  Staff  Response  to  another  section. 

223  Rexmttd  copy:  Immediate  Request  for  Fire  Support. 

224  Rexmttd  copy:  Preplanned  Request  for  Fire  Support. 

225  Rexmttd  copy:  Target  (Intel). 

226  Rexmttd  copy:  Fire  Support  Status 

Initiated  by  G2  Section 

230  Query  to  another  staff  section. 

232  Info  copy:  Frag  Order  (Intel). 

233  Info  copy:  Division  Intsum. 

234  Rexmttd  copy:  NBC  Report. 

235  Rexmttd  copy:  Weather  Forecast. 

236  Intel  Para  Division  Sitrep. 

237  Intel  Estimate. 

238  Intel  Annex. 

239  Staff  Request  to  another  section. 

240  Staff  Response  to  another  section. 

241  Rexmttd  copy:  Bde  Intsum. 

242  Rexmttd  copy:  Shell  Report. 

243  Rexmttd  copy:  Spot  Report. 

>24^  Rexmttd  copy:  Combat  Intelligence  Report. 

245  Rexmttd  copy:  Post  Strike  Damage  Report. 

246  Rexmttd  copy:  Estimate  of  Enemy  Strength. 

247  Rexmttd  copy:  Target  List  (Intel). 


Table  4-4.  Class  2  Events  (Continued). 


Event  Number  Definition  of  Events 


Initiated  by  G3  Section 

250  Query  to  another  staff  section. 

252  Info  copy:  Frag  Order  (OPS) 

253  Info  copy:  Division  Sitrep. 

254  Info  copy:  Nuclear  Warning  Order. 

255  Info  copy:  Air  Defense  Warning  Order. 

257  Info  copy:  Operations  Plan 

258  Operations  Estimate. 

259  Rexmttd  copy:  Initial  Enemy  Contact  Report. 

260  Rexmttd  copy:  Unit  Progress  Report. 

261  Rexmttd  copy:  Loss-of-Contact/Friendly  Unit  Report. 

262  Rexmttd  copy:  Electronic  Order  of  Battle. 

263  Staff  Request  to  another  section. 

264  Staff  Response  to  another  section. 

265  Rexmttd  copy:  Bde  Sitrep. 

267  Rexmttd  copy:  Organic  Aviation  Sortie  Status. 

Initiated  by  Gl/64  Section 

280  Query  to  another  staff  section. 

282  Info  copy:  Frag  Order  (CSS) 

283  Info  copy:  Division  Personnel  Daily  Summary. 

284  Info  copy:  Periodic  Logistic  Report. 

285  Info  copy:  Personnel  Requisition. 

287  Combat  Service  Support  Estimate. 

288  Combat  Service  Support  Annex. 

289  Staff  Request  to  another  section. 

290  Staff  Response  to  another  section. 

291  Rexmttd  copy:  Bde/Bn  Personnel  Daily  Summary. 

292  Rexmttd  copy:  CAPE  Report. 

296  Rexmttd  copy:  Di scorn  Sitrep. 


4-14 


directly  affecting  the  conflict  will  be  "played"  as  part  of  staff  actions 
required  of  players  in  populated  staff  modules,  but  will  not  be  linked 
to  the  battle  outcome  generator. 

The  event  numbers  and  definitions  of  the  Class  3  events  are 
shown  in  Table  4-5.  The  table  specifies  27  different  staff  outputs, 
numbered  according  to  the  standard  convention  and  with  the  embedded 
message  reference  numbers  used  with  interface  events. 

Class  3  events  are  further  specified  in  Design  Notes  E  and  J.  The 
distinction  between  the  two  kinds  of  Class  3  events  is  not  shown  in  Table 
4-5,  but  is  given  in  precise  detail,  first,  under  the  message  references 
in  Design  Note  A,  and  then  in  the  detailed  specification  in  Design  Note 
E.  The  corresponding  event  thread  charts  for  Class  3  events  are 
presented  in  Design  Note  J. 

4. 1.2. 4  Staff  Input  Events 

Class  4  events  are  the  input  tactical  information  messages  to 
the  staff  modules  from  the  interior  modules  of  the  simulation.  They 
will  be  embodied  in  periodic  reports  and  spot  reports  coming  from  the 
subordinate  units  simulated  in  the  BOG,  and  in  fragmentary  orders,  in¬ 
telligence  reports,  etc.  coming  from  the  other  units  module. 

Class  4  reports  will  be  the  basic  vehicles  by  which  the  staff 
modules  will  acquire  and  maintain  their  own  bodies  of  perceived  infor¬ 
mation  about  the  "state  of  the  battle."  All  staff  input  messages  will 
reflect  not  only  certain  errors  and/or  omissions  in  the  message  content 
but  also  simulated  delays  in  the  times  of  arrival  in  the  hands  of  the 
receiving  staff  sections,  so  that  the  state  of  knowledge  about  the 
division-level  combat  held  by  the  staff  elements  (or  the  single  Red 
Command  Module)  will  always  be  at  variance  with,  and  delayed  from,  the 
actual  simulated  battle  events. 

The  event  nunbers  and  definitions  of  the  Class  4  events  are 
shown  in  Table  4-6.  The  table  specifies  42  different  staff  inputs, 
numbered  according  to  the  standard  convention  and  with  embedded  message 
reference  numbers. 

Class  4  events  are  further  specified  in  Design  Notes  F  and  J. 

Staff  inputs,  like  other  interface  events,  are  divided  into  two  types: 
those  which  update  the  state  of  knowledge  about  the  on-going  conflict 
and  those  which  serve  as  part  of  a  planning  activity  being  pursued  at 
the  same  time.  Staff  inputs  are  also  divided  into  those  messages 
which  may  be  "queried"  and  those  which  may  not.  These  distinctions 
are  drawn  precisely  in  the  specification  given  in  Design  Note  F.  The 
event  thread  charts  covering  all  Class  4  events  are  given  in  Design 
Note  J. 
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Table  4-5.  Class  3  Events. 


Event  Number  Definition  of  Event 


Issued  by  Command  Group 

301  Query  to  subordinate  units. 

302  Nuclear  Release  Request. 

Issued  by  Fire  Support  Element 

310  Query  to  subordinate  units. 

311  Query  to  Corps  regarding  its  Frag  Order  (FS). 

312  Fragmentary  Order  (FS). 

313  Immediate  Request  to  Corps  for  Fire  Support. 

314  Preplanned  Request  to  Corps  for  Fire  Support. 

Issued  by  G2  Section 

330  Query  to  subordinate  units. 

331  Query  to  Corps  regarding  its  Frag  Order  (Intel) 

332  Fragmentary  Order  (Intel). 

333  Division  Intsum. 

334  NBC  Report. 

Issued  by  G3  Section 

350  Query  to  subordinate  units. 

351  Query  to  Corps  regarding  its  Frag  Order  (OPS). 

352  Fragmentary  Order  (OPS). 

353  Division  Sitrep. 

354  Nuclear  Warning  Order. 

355  Air  Defense  Warning  Order. 

356  Request  for  Reserves. 

357  Operations  Plan. 

Issued  b.y  G1/G4  Section 

380  Query  to  subordinate  units. 

381  Query  to  Corps  regarding  its  Frag  Order  (CSS). 

382  Fragmentary  Order  (CSS). 

383  Division  Personnel  Daily  Summary. 

384  Periodic  Logistics  Report. 

385  Personnel  Requisition. 

386  Immediate  Request  to  Corps  for  Logistic  Support 


Event  Number 


Table  4-6.  Class  4  Events. 
Definition  of  Event 


Received  by  Command  Group 

(None  of  the  following  reports  are  distributed  automatically  to  the 
CG,  but  some  may  be  procured  through  "query.") 

Received  by  Fire  Support  Element 

415  Arty  Sitrep. 

416  Arty  Target  List. 

417  Friendly  Unit  Fire  Support  Capability. 

418  Enemy  Unit  Fire  Support  Capability. 

423  Immediate  Request  for  Fire  Support. 

424  Preplanned  Request  for  Fire  Support. 

425  Target  Report  (Intel). 

426  Fire  Support  Status  Report. 

427  Query  from  addressee  on  issued  Frag  Order  (FS). 

428  Fire  Support  Estimate/Annex. 

429  Frag  Order  (FS)  from  Corps. 

Received  by  G2  Section 

434  NBC  Report. 

435  Weather  Forecast. 

441  Bde  Intsum. 

442  Shell  Report. 

443  Spot  Report. 

444  Combat  Intelligence  Report. 

445  Post  Strike  Damage  Report. 

446  Estimate  of  Enemy  Strength  Report. 

447  Target  List  (Intel). 

448  Query  from  addressee  on  issued  Frag  Order  (Intel). 

449  Frag  Order  (Intel)  from  Corps. 

Received  by  G3  Section 

459  Initial  Enemy  Contact  Report. 

460  Unit  Progress  Report. 

461  Loss-of-Contact/Friendly  Unit  Report. 

462  Enemy  Electronic  Order  of  Battle. 

465  Bde/Bn  Sitrep. 

466  Air  Defense  Alert. 

467  Aviation  Sortie  Status  Report. 

468  Query  from  addressee  on  issued  Frag  Order  (OPS). 

469  Query  from  addressee  on  issued  Nuclear  Warning  Order. 

470  Query  from  addressee  on  issued  Air  Defense  Warning  Order. 

471  Frag  Order  (OPS)  from  Corps. 

472  Operations  Special  Estimate/Annex. 


i 


i 
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Table  4-6.  Class  4  Events  (Continued). 


Event  Number 


Definition  of  Event 


Received  by  G1/G4  Section 

486  Immediate  Request  for  Logistic  Support. 

491  Bde/Bn  Personnel  Daily  Summary. 

492  CAPE  Report. 

493  Preplanned  Request  for  Logistic  Support. 

494  Query  from  addressee  on  issued  Frag  Order  (CSS). 

495  Frag  Order  (CSS)  from  Corps. 

496  Division  Support  Command  Sitrep. 

497  CMO  Estimate/Annex. 


4.1 .2.5  Battle  Events 


Class  5  events  cover  all  significant  occurrences  taking  place 
in  the  interior  modules  of  the  simulation.  These  events  include  not 
only  the  actual  maneuvers  and  engagements  by  units  of  the  opposing 
forces  but  also  all  the  responses  to  Class  3  staff  outputs  and  progen¬ 
itors  for  Class  4  staff  inputs. 

The  maneuver  and  combat  events  in  the  BOG,  as  well  as  certain 
target  detection  and  intelligence  processing  events,  have  not  yet  been 
fully  defined.  It  can  be  seen  that  these  events  have  no  direct  rela¬ 
tionship  with  the  separately  defined  tactical  information  messages  so 
that  their  event  numbers  do  not  conform  to  the  rule  about  embedded 
message  reference  numbers.  Battle  events  of  this  type  are  instead 
numbered  in  such  a  manner  that  they  fall  into  the  unused  spaces  in  the 
range  between  500-599. 

The  progenitors  and/or  follow-on  events  associated  with  specific 
tactical  messages,  on  the  other  hand,  do  conform  to  the  rule  even  though 
they  are  not  themselves  interface  events.  It  will  be  seen,  for  example, 
that  events  defined  as  follows: 

"Addressee  received  Query  from  Command  Group.", 

"Addressee  received  Frag  Order  (OPS).",  and 

"Corps  receives  Division  Intsum." 

are  the  follow-on  events  associated  with  specific  staff  output  messages, 
while  events  defined  as  follows: 

"Preparation  of  Post  Strike  Damage  Report.", 

"Corps  xmits  Frag  Order  (OPS).",  and 

"Prepration  of  CMO  Estimate/Annex." 

are  progenitor  events  to  their  specific  staff  input  messages.  Since 
the  progenitor  or  follow-on  relationship  is  implicit  for  all  defined 
tactical  messages  except  those  associated  solely  with  staff  coordina¬ 
tion  exchanges,  the  rule  of  embedded  reference  numbers  is  carried  over 
to  these  Class  5  events. 

The  event  numbers  and  definitions  of  the  Class  5  events  identi¬ 
fied  so  far  are  shown  in  Table  4-7.  The  table  specifies  61  events  con¬ 
forming  to  the  rule  for  embedded  reference  numbers  and  12  events  associ¬ 
ated  with  maneuvers  and  engagements.  The  latter  type  events  are  marked 
with  asterisks.  As  new  definitions  are  derived  for  these  events,  they 
will  be  inserted  in  the  available  unused  spaces  in  the  table. 
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Table  4-7.  Class  5  Events. 


Event  Number  Definition  of  Event 


Battle  Events 

500*  Battefield  clock  indicates  it  is  time  to  initiate  ordered  action. 

501  Addressee  receives  Query  from  Command  Group. 

502  Corps  receives  Nuclear  Release  Request. 

503*  Unit(s)  begin  moving. 

504*  Unit(s)  cross  phase  line  or  check  point. 

505*  Unit(s)  close  at  destination. 


508*  Enagement  Phase  nn;  Battle  Array  nnn. 

510  Addressee  receives  Query  from  FSE. 

511  Corps  receives  Query  on  its  Frag  Order  (FS). 

512  Addressee  receives  Frag  Order  (FS). 

513  Corps  receives  Immediate  Request  for  Fire  Support. 

514  Corps  receives  Preplanned  Request  for  Fire  Support. 

515  Preparation  of  Arty  Sitrep. 

516  Preparation  of  Arty  Target  List. 

517  Preparation  of  Friendly  Unit  Fire  Support  Capability. 

518  Preparation  of  Enemy  Unit  Fire  Support  Capability. 

519*  Enemy  target  attacked  by  conventional  weapons. 

520*  Enemy  target  attacked  by  nuclear  weapon. 


523  Preparation  of  Immediate  Request  FS. 

524  Preparation  of  Preplanned  Request  FS. 

525  Preparation  of  Target  Report  (Intel). 

526  Preparation  of  Fire  support  Status  Report. 

528  Preparation  of  Fire  Support  Estimate/Annex. 

529  Corps  xmits  Frag  Order  (FS). 

530  Addressee  receives  Query  from  G2. 

531  Corps  receives  Query  on  its  Frag  Order  (Intel). 

532  Addressee  receives  Frag  Order  (Intel). 

533  Corps  receives  Division  Intsum. 

534  Preparation  of  NBC  Report  or  Corps  receipt  thereof. 

535  Preparation  of  Weather  Forecast. 

536*  Friendly  unit(s)  attacked  by  conventional  weapons. 

537*  Freindly  unit(s)  attacked  by  nuclear  weapon. 

538*  Assessment  of  damage  from  conventional  weapons. 

539*  Assessment  of  damage  from  nuclear  weapons- 

540*  Intelligence  Received. 

r'4 1  Preparation  of  B^e  Intsum. 

•  number  contains  no  embedded  message  reference  number. 
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Table  4-7.  Class  5  Events  (Continued). 


Event  Number 


Definition  of  Event 


Battle  Events  -  continued 

542  Preparation  of  Shell  Report. 

543  Preparation  of  Spot  Report. 

544  Preparation  of  Combat  Intelligence  Report. 

545  Preparation  of  Post  Strike  Damage  Report. 

546  Preparation  of  Estimate  of  Enemy  Strength. 

547  Preparation  of  Target  List  (Intel). 


549  Corps  xmits  Frag  Order  (Intel). 

550  Addressee  receives  Query  from  63. 

551  Corps  receives  Query  on  its  Frag  Order  (OPS). 

552  Addressee  receives  Frag  Order  (OPS). 

553  Corps  receives  Division  Sitrep. 

554  Addressee  receives  Nuclear  Warning  Order. 

555  Addressee  receives  Air  Defense  Warning  Order. 

556  Corps  receives  Request  for  Reserves. 

557  Corps  receives  Operations  Plan. 


559 

560 

561 

562 


Preparation  of 
Preparation  of 
Preparation  of 
Preparation  of 


Initial  Enemy  Contact  Report. 

Unit  Progress  Report. 
toss-of-Contact/Friendly  Unit  Report. 
Enemy  Electronic  Order  of  Battle. 


565 

566 

567 


Preparation 

Preparation 

Preparation 


of  Bde/Bn  Sitrep. 

of  Air  Defense  Alert. 

of  Organic  Aviation  Sortie  Status  Report. 


571  Corps  xmits  Frag  Order  (OPS). 

572  Preparation  of  Operations  Special  Estimate/Annex. 


580  Addressee  receives  Query  from  G1/G4. 

581  Corps  receives  Query  on  its  Frag  Order  (CSS). 

582  Addressee  receives  Frag  Order  (CSS). 

583  Corps  receives  Division  Personnel  Daily  Summary. 
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Table  4-7.  Class  5  Events  (Continued). 


Event  Number  Definition  of  Event 


Battle  Events  -  continued 

584  Corps  receives  Periodic  Logistics  Report. 

585  Corps  receives  Personnel  Requisition. 

586  Preparation  of  Immed.  Req.  for  Logistic  Support  or  Corps  receipt. 


591  Preparation  of  Bde/Bn  Personnel  Daily  Summary. 

592  Preparation  of  CAPE  Report. 

593  Preparation  of  Preplanned  Request  for  Logistic  Support. 

595  Corps  xmits  Frag  Order  (CSS). 

596  Preparation  of  DisCom  Sitrep  or  Corps  receipt  thereof. 

597  Preparation  of  CMO  Estimate/Annex. 


I 
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The  Class  5  events  are  further  specified  in  Design  Notes  H  and 
J.  The  distinction  between  the  various  kinds  of  Class  5  events  and 
their  interaction  for  intelligence  is  given  in  detail  in  Design  Note  H. 
The  corresponding  event  thread  charts  for  Class  5  events  are  presented 
in  Design  Note  J. 

4. 1.2. 6  Staff  Interfacing  With  Their  ADP  Terminals 

Class  6  event:  are  defined  as  those  occurrences  that  take  place 
when  members  of  a  staff  seciton  enter  or  read  out  tactical  information 
while  sitting  at  the  ADP  terminal.  They  are  applicable  to  the  design 
only  when  the  simulation  rules  have  been  expanded  to  accommodate  comput¬ 
erized  decision-making  aids  and  the  player  modules  have  been  equipped 
with  TOS-emulating  terminals. 

Class  6  events  have  not  yet  been  defined. 

4.1.3  Computer  Assistance 

Any  implementation  of  the  system  design  concept  described  so 
far  must  address  the  following  fundamental  questions  regarding  the  or¬ 
ganization  and  play  of  the  simulated  combat: 

•  How  should  the  data  bases  be  organized  in  order  to  store 
and  to  manipulate  the  Blue  and  Red  division-level  forces, 
the  Blue  and  Red  perceptions  of  their  own  and  the  enemy 
forces,  the  schedule  of  events  unfolding  in  the  scenario, 
and  the  formats  used  in  the  tactical  information  flow? 

•  What  preprocessing  activities  are  required  to  set  up  the 
play  of  a  specified  scenario? 

•  By  what  means  do  the  investigators/controllers  set  the 
control  parameters  so  that  the  exercise  reflects  the 
desired  research  objectives? 

»  What  procedures  should  the  controllers  then  use  to  control 
the  play  and,  at  the  same  time,  maintain  the  desired  slow 
time,  real  time,  or  fast  time  pace  of  events? 

Each  of  these  basic  questions  brings  into  focus  a  separate  aspect  of  the 
role  of  computer  assistance  in  making  the  simulation  an  effective  tool 
for  research,  development,  and  training. 

The  system  design  concept  could,  in  principle,  be  implemented 
and  played  as  a  slow  time,  all -manual  game  without  any  computer  assis¬ 
tance.  Indeed,  the  integrated  battle  simulation  could  be  run  using  no 
other  materials  than  the  equipment  for  the  populated  staff  modules, 
blackboards,  preprinted  message  forms,  maps,  books  or  compendia  of  sim¬ 
ulation  rules,  look-up  tables,  pencils,  and  paper.  Preparation  for 
th  play  and  the  manipulation  of  the  simulation  variables  during  the 
game  would  require  large  amounts  of  time  and  manpower.  A  large  number 


of  qualified  controllers  would  be  required,  first,  to  set  up  the  opposing 
force  organizations  on  blackboards  and  deploy  these  forces  on  the  con¬ 
troller's  situation  map,  and  second  to  modify  the  blackboard  data  bases 
and  maintain  the  situation  map  as  the  events  of  the  simulated  battle 
unfolded.  A  slow  time  game  under  these  circumstances  is  entirely  feas¬ 
ible,  but  it  is  doubtful  that  the  team  of  controllers  could  perform  its 
functions  and  still  keep  up  with  a  simulated  time  clock  running  at  real 
time.  In  earlier  attempts  at  all-manual  simulations'  it  was  found  that 
it  took  as  long  as  8  hours  to  play  1  hour  of  combat. 

The  discussion  that  follows  addresses  the  various  ways  in  which 
a  computer  could  be  used  to  assist  in  (1)  the  preprocessing  and  data 
management  of  the  simulation  data  bases,  (2)  the  interactive  control  of 
the  event-store  simulator,  (3)  the  use  of  interactive  terminals  for 
players  (to  simulate  an  ADP-assisted  staff),  and  (4)  the  post-processing 
functions.  The  discussion  begins  by  considering  the  size  and  basic 
organization  of  the  information  or  data  on  which  the  exercise  of  the 
model  would  be  based.  It  then  follows  with  separate  paragraphs  devoted 
to  the  different  computer  assistance  areas  above  and  emphasizing  the 
manner  in  which  these  areas  relate  to  the  fundamental  questions. 

4. 1.3.1  Data  Organization 

One  measure  of  the  size  of  the  model  design  will  be  the  maximum 
number  of  entities  and  state  variables  (i.e.,  limit  parameters)  required 
to  define  the  level  of  resolution  of  the  combat  units  in  the  opposing 
forces,  the  maximum  number  of  such  units  allowed  on  each  side,  the 
geographic  size  of  the  tactical  area  of  play,  and  the  table  or  list  of 
scheduled  events  used  during  the  play.  These  sizing  parameters  and  the 
basic  organization  of  the  major  data  groups  in  the  model  must  be  speci¬ 
fied  whether  or  not  the  simulation  is  implemented  simply  as  a  manual 
game  or  as  a  computerized  research  tool.  Sizing  and  structure  con¬ 
siderations  will  determine  the  requirements  for  preprinted  message 
forms  and  for  blackboard  space,  in  an  all-manual  implementation;  they 
will  define  the  basic  organization  of  files  and  internal  data  arrays 
for  a  system  that  is  partially  or  fully  computerized. 

The  sizing  estimates  presented  here  are  based  on  the  kilobyte 
as  the  unit  of  measure  of  the  system  data.  A  kilobyte  is  a  "chunk"  of 
information  equivalent  to  1000  letters,  characters,  or  numeric  digits. 

The  major  data  groups  required  in  the  simulation  are  identified 
as  follows: 

•  Real  World  Data  Base 

•  Blue  Perceived  Data  Base 
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•  Red  Perceived  Data  Base 

•  Event  Table 

•  Message  Format  Specifications  and  Data  Element  Dictionary. 

Each  of  the  major  repositories  will  have  its  own  organization  of  data 
subgroups  and  elementary  data  items.  The  number  of  entries  in  each  sub¬ 
group  will  be  fixed,  and  each  such  number  will  represent  one  of  the 

basic  sizing  parameters  of  the  system.  All  major  groups  except  the  last 
will  be  dynamic  storage  media  in  the  sense  that  individual  elementary 
data  items  in  them  will  be  capable  of  being  accessed,  updated,  and/or 
erased  during  the  course  of  the  play.  The  message  format  specifications 
and  data  element  dictionary  alone' will  be  "read  only"  data,  since  the 
formats  and  the  data  element(s )/data  chains  employed  in  simulation  will 
be  fixed  and  invariant. 

The  sizes  of  the  major  data  groups,  measured  in  kilobytes,  are 
shown  in  Figure  4-3.  The  figure  is  scaled  to  show  the  relative  amounts 
of  data  space  required  for  each  group.  The  overall  requirement  is 
approximately  316  kilobytes. 

The  basic  functions  of  these  major  data  groups,  their  principal 
subgroups,  and  the  basis  for  the  individual  data  space  requirements  are 
discussed  below. 

Real  World  Data  Base.  The  real  world  data  base  will  contain 
the  ground  truth  facts  of  the  simulated  battle  as  it  continuously  un¬ 
folds  by  the  occurrences  of  battle  events.  The  basic  data  subgroups 
are  (1)  the  Blue  force  table,  (2)  the  Red  force  table,  and  (3)  the 
battle  array  file. 

The  force  tables  for  the  opposing  sides  will  have  identical 
structure.  Each  table  will  be  broken  down  into  a  unit-type  subtable 
and  a  uni t  subtable.  The  unit-type  subtable  will  consist  of  up  to  25 
unit  type  entries  where  each  entry  contains  unit  type  identification 
data  and  the  mathematical  force  balance  coefficients  associated  with 
its  weapons.  Although  the  specific  data  items  have  not  yet  been  defined? 
it  is  estimated  that  each  unit-type  entry  will  require  120  bytes  or  .12 
kilobytes  of  information,  making  the  total  requirement  for  the  subtable 
.12  x  25  =  3  kilobytes. 

It  should  be  noted  that  the  information  in  the  unit-type  sub¬ 
table  will  remain  invariant  during  the  course  of  play,  but  that  composi¬ 
tion  of  the  forces,  in  terms  of  the  types  of  combat  and  support  units, 
may  be  varied  with  each  new  scenario  prepared  for  the  play. 


*See  page  H-ll  of  Detailed  Design  Mote  H  in  the  companion  volume  for  an 
example  of  a  unit  type  subtable.  The  state  variables  needed  for  each 
type  unit  are  a  function  of  the  content  of  the  Class  3  and  4  messages 
to  be  processed  and  the  combat  interaction  algorithms  employed. 
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REAL  WORLD  DATA  BASE 

•  Approximately  86  kilobytes  of  data 

•  Includes:  Blue  force  table 

Red  force  table 
Battle  array  file 


BLUE  PERCEIVED  DATA  BASE _ 

•  Approximately  25  kilobytes  of  data 


RED  PFRCEIVFO  DATA  BASE _ 

•  Approximately  15  kilobytes  of  data 


EVENT  TABLE _ _ 

•  Approximately  90  kilobytes  of  data 

•  Accommodates  up  to  600  scheduled  (projected)  events  at  any 
given  time 

•  Each  scheduled  event  contains  full  message  content  or  full 
event  description 


FORMAT  SPECIFICATIONS  AND  DATA  ELEMENT  DICTIONARY _ 

•  Approximately  100  kilobytes  of  data 

•  "Read  only"  storage 

•  Includes:  Standard  tactical  message  formats 

Separate  dictionaries  for  all  format  entry 

variables 

Rate  of  advance  tables,  etc. 


Figure  4-3.  Sizes  of  the  Major  Data  Groups. 
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Examples  of  unit  types  one  might  use  in  synthesizing  a  Blue 
force  are  as  follows: 

•  Mechanized  Infantry  Company 

•  Tank  Company 

•  Armored  Cavalry  Troop 

•  Artillery  Battery  (Type  1) 

•  Artillery  Battery  (Type  2) 

•  Engineer  Company  (Type  1) 

•  Engineer  Company  (Type  2) 

•  Air  Defense  Battery 

•  Aviation  Company. 

Each  of  these  unit  types  will  reflect  a  different  set  of  mathematical 
coefficients  to  be  used  in  the  force  balance  formulae  in  the  battle 
events. 


The  unit  subtable  will  consist  of  up  to  150  unit  entries  where 
each  entry  contains  all  the  data  and  running  variables  associated  with 
a  specific  company-equivalent  unit  in  the  division.  The  specific  data 
items  necessary  to  cover  all  the  data  and  running  variables  have  not 
yet  been  defined,  but  the  following  categories  of  items  have  been 
identified: 

•  Unit  identification  and  unit  type  designation 

•  Chain  of  command  in  the  current  organization  fO'*  combat 

•  Posture  state,  location,  and  status  of  the  unit 

•  Personnel  strength  and  resources. 

All  categories  but  the  first  will  be  subject  to  modification  or  update 
during  the  course  of  the  play.  It  is  estimated  that  each  entry  will 
require  200  bytes  or  .2  kilobytes  of  data  space  to  cover  these  cate¬ 
gories,  so  that  each  unit  subtable  will  require  altogether  .2  x  150  = 

30  kilobytes. 

The  third  subgroup  in  the  real  world  data  base  will  be  the  battle 
array  file.  This  file  will  contain  arrays  of  data  identifying  the  spe¬ 
cific  maneuver  units  and  combat  support  units  on  each  side  during  the 
time  the  opposing  forces  are  engaged  in  active  combat.  Separate  arrays 
will  exist  for  different  battles  taking  place  in  different  locations  in 
the  tactical  area  of  play.  An  individual  battle  array  will  be  created 
whenever,  during  the  course  of  a  simulated  exercise,  Blue  units  and 
opposing  Red  units  first  make  contact.  The  array  data  will  remain  on 
file  until  the  outcome  of  the  engagement  is  resolved  and  the  opposing 
forces  have  broken  off  contact. 
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The  size  of  the  battle  array  file  is  estimated  to  be  20  kilo¬ 
bytes.  The  limit  parameters  on  the  maximum  number  of  separate  arrays 
and  the  maximum  number  of  units  on  each  side  that  can  be  engaged  have 
not  yet  been  determined. 

To  summarize  the  sizing  and  data  space  requirements  of  the  real 
world  data  base:  the  basic  design  will  accomodate  a  Blue  force  and  a 
Red  force,  each  consisting  of  up  to  150  company-sized  units.  The  com¬ 
position  of  the  forces  may  consist  of  up  to  25  different  types  of  man¬ 
euver  units,  combat  support  units,  and  combat  service  support  units. 
During  an  exercise,  these  forces  may  be  grouped  together  in  a  number  of 
separate  battle  arrays.  The  maximum  number  of  arrays  and  the  maximum 
number  of  opposing  units  in  a  single  array  have  not  been  determined. 

The  data  space  requirements,  based  on  these  subgroups,  are  as 

follows: 


Blue  force  table: 

Red  force  table: 

Battle  array  file: 

Total  Requirement 


3  +  30  =  33  kilobytes 

3  +  30  =  33  kilobytes 

20  =  20  kilobytes 

=  86  kilobytes 


Perceived  Data  Bases.  The  perceived  data  base  on  each  side  con¬ 
sists  of  the  side's  perception  of  its  own  troop  list  and  operations 
SITMAP  as  well  as  the  enemy  order  of  battle  and  dispositions.  The  real 
world  data  base  and  the  separate  perceived  data  bases  are  conceived  as 
distinct  bodies  of  information  because  neither  side  will  ever  enjoy  true 
and  full  knowledge  of  the  deployment  of  the  units  of  the  other  side  nor 
even  up-to-date  and  precise  knowledge  of  its  own  troops.  Accordingly, 
the  basic  design  concept  includes  a  Blue  and  Red  perceived  data  base 
each  containing  unaggregated  information  about  its  own  troops  and  the 
enemy  forces.  During  the  course  of  the  play,  the  information  in  these 
data  bases  will  be  continually  modified  by  the  occurrences  of  the  Class 
5  report  generation  events  (see  paragraph  4. 1.2. 5).  The  occurrences 
will  usually  be  followed  by  corresponding  Class  4  events  at  which  times 
the  staff  modules  will  "receive"  tactical  information  messages.  The 
messages  will  be  formatted  according  to  standard  message  formats  and 
based  on  data  aggregated  from  the  perceived  data  base.  Thus,  the  "state 
of  battle"  reflected  in  the  information  will  always  be  delayed  in  time 
and  subject  to  errors  and  omissions  with  respect  to  the  true  facts  in 
the  real  world  data  base. 


For  certain  experimental  or  training  purposes  it  may  be  desirable 
for  RED  to  have  access  to  the  undegraded,  undelayed  data  stored  in  the 
real  world  data  base.  For  such  applications,  the  controller  would  assume 
the  functions  of  the  RED  player.  As  controller,  he  would  already  have 
access  to  real  world  information  in  order  to  maintain  his  real  world 
situation  map  and  could,  therefore,  play  RED  with  perfect  information 
(see  paragraph  4.2.2  below). 
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In  concept,  the  perceived  data  base  will  always  exist  in  two 
forms:  first  as  tabular  arrays  of  data  available  ordinarily  only  to  the 
controller(s)  and/or  computer,  and  second  as  the  series  of  troop  lists, 
modified  organizations  for  combat,  situation  map  overlays,  numerous  files, 
etc.,  set  up  and  maintained  by  human  players  in  populated  staff  modules 
during  an  exercise.  The  first  form  may  be  thought  of  as  the  body  of 
facts  about  the  conflict  marshalled  by  the  Blue  or  Red  sides,  while  the 
second  form  will  reflect  the  way  the  commander  and  his  staff  organize, 
aggregate,  and  sift  the  known  facts  to  facilitate  decision  making. 

The  tabular  array  form  may  also  be  used  for  certain  Class  1 
events,  executed  in  simulated  staff  modules.  Whenever  the  simulated 
staff  section  must  reference  its  own  files,  maps,  or  charts  in  order  to 
respond  to  staff  queries  or  requests,  the  simulated  action  step  will 
entail  the  aggregation  and  formatting  of  data  from  the  tabular  array. 

The  Blue  and  Red  perceived  data  bases  will  exhibit  a  fundamental 
asymmetry  in  the  system  design  concept.  Both  data  bases  will  contain 
the  tabular  arrays  of  unaggregated  data  covering  the  status  and  disposi¬ 
tions  of  their  own  units  and  the  garnered  intelligence  about  the  oppos¬ 
ing  forces.  But  the  Blue  data  base  will  contain  an  additional  subgroup 
of  data  called  the  "scratch  pad  area." 

The  scratch  pad  area  is  conceived  as  the  supplementary  data  space 
that  will  be  required  whenever  the  Blue  Staff  Modules  are  played  using 
Class  6  events  under  an  ADP-assisted  staff  concept.  Although  the  pre¬ 
cise  formulation  of  the  decision-making  aids  are  not  known  at  this  time, 
it  is  assumed  that  the  field  computer  system  will  eventually  provide  (1) 
access  to  the  "raw  data"  in  the  tabular  arrays  and  (2)  the  ability  to 
aggregate,  reorganize,  disregard,  or  extrapolate  the  information  in  order 
to  address  tactical  decision  alternatives.  The  scratch  pad  area  is  the 
place  where  the  data  formulation  will  be  stored. 

The  tabular  arrays  on  both  sides  will  consist  of  two  subtables 
each.  The  subtables  wll  contain  150  entries  each.  The  first  subtable 
will  be  the  FRENSIT  table;  the  150  entries  will  correspond  to  the  150 
unit  table  entries  of  the  real  world  data  base  friendly  forces.  The 
second  subtable  will  be  the  ENSIT  table;  its  150  entries  will  correspond 
to  the  150  units  of  the  enemy  forces.  The  elementary  data  items  in 
FRENSIT  and  ENSIT  tables  will  consist  of  "state-of-knowledge"  indices* 
and  data-time-group  records  of  the  last  (latest)  reporting  times.  It  is 
estimated  that  individual  entries  will  require  about  50  bytes  each,  so 
that  a  single  full  tabular  array  will  have  a  data  space  requirement  of 

150  x  (.050  +  .050)  =  15  kilobytes. 

It  should  be  noted  that  the  tabular  arrays  will  contain  only  the 
current,  or  latest  reported,  data  on  friendly  and  enemy  units;  they  will 

*A  state-of-knowledge  (S0K)  index  is  a  one-digit  integer  whose  value 
represents  the  current  state  of  knowledge  about  an  item  of  friendly  or 
enemy  force  information. 


4-29 


not  reflect  historical  or  out-of-date  information.  If  out-of-date  in¬ 
formation  is,  or  becomes,  an  important  part  of  decision  formulation, 
these  data  may  be  saved  for  retrieval  by  "rolling  out"  the  tabular  arrays 
periodically  on  magnetic  tape. 

The  scratch  pad  area  on  the  Blue  side  is  arbitrarily  assumed  to 
require  about  10  kilobytes  of  data  space. 

To  summarize  the  sizing  and  data  space  requirements  of  the  per¬ 
ceived  data  bases:  the  basic  design  will  include  separate  Blue  and  Red 
perceived  data  bases  whose  structure  will  match  any  real  world  data  base 
force  tables.  No  additional  constraints  will  be  imposed  beyond  those 
already  cited  for  the  real  world  data. 

The  Blue  perceived  data  base,  which  contains  both  the  tabular 
array  and  the  scratch  pad  area,  will  have  a  space  requirement 

•»  15  +  10  =  25  kilobytes. 

* 

The  Red  perceptions,  consisting  solely  of  a  tabular  array,  will  have  a 
data  space  requirement  of  15  kilobytes. 

Event  Table.  The  Event  Table  is  a  large  data  storage  array 
necessary  to  implement  the  event-store  mechanism  on  which  the  battle 
,  simulation  will  be  based.  The  basic  operation  of  the  event-store  tech¬ 

nique  and  the  role  served  by  the  Event  Table  are  described  in  Section  3.3. 

The  Table  will  consist  of  spaces  for  up  to  600  scheduled  events. 

A  scheduled  event  is  a  significant  occurrences  projected  to  occur  at 
some  time  in  the  future  of  the  current  reading  of  the  simulated  clock. 
During  the  course  of  the  play,  scheduled  events,  that  is,  individual 
entries  in  the  Event  Table,  will  be  continually  extracted  and  erased, 
leaving  empty  spaces  in  the  table.  With  the  processing  of  each  such 
event,  new  events  are  usually  generated  and  these  newly  scheduled  events 
are  put  into  the  table,  inserting  the  data  in  the  firt  blank  or  empty 
space  encountered.  The  central  problem  in  implementing  the  technique 
is  that  of  stringing  the  scheduled  events  together  continually  so  that 
the  correct  time  sequence  of  event  processing  is  preserved.  Under  pro¬ 
per  sequencing,  the  "fill"  in  the  Event  Table,  that  is,  the  number  of 
non-blank  entries,  will  dynamically  change  up  and  down  depending  on  the 
particular  event  threads  unfolding  in  the  simulated  battle. 

Every  non-blank  entry  in  the  table  will  contain  the  following 
data  items  or  data  subgroup: 

•  Event  time  (measured  in  minutes)  10  bytes 

•  Event  type  index  4  bytes 

•  Previous  event  index  3  bytes 

•  Next  event  index  3  bytes 


i 
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Event  message  content  or  battle  event 
description  130  bytes 


The  further  break-down  of  the  event  message  content  or  battle  event  des¬ 
cription  subgroup  has  not  yet  been  made.  It  is  proposed,  however,  that 
this  subgroup  contain  sufficient  data  to  fill  in  all  the  blanks  in  a 
one-page  tactical  information  message,  or  alternatively,  to  provide  full 
confirmation  of  the  conditions  on  which  a  battle  event  is  contingent. 

The  Event  Table,  under  this  scheme  of  data  organization,  will 
require  altogether 

600  x  (.010  +  .004  +  .003  +  .003  +  .130)  =  90  kilobytes. 

Message  Formats,  Dictionary,  and  Other  Tables.  The  last  required 
major  data  group  is  significant  primarily  because  it  consists  of  all  the 
"hard  wired"  data  in  the  battle  simulation.  The  basic  system  design 
clearly  reflects  two  distinct  kinds  of  elements:  variable  elements  and 
hard  wired  elements.  The  variables  are  the  input  data,  the  selectable 
configurations  of  play,  the  range  of  alternative  scenarios,  and  the 
control  parameter  settings  for  alternative  research  objectives.  The 
hard  wired  elements,  on  the  other  hand,  are  the  simulation  rules,  the 
sizing  parameters,  the  event  threads  specifying  the  logical  progenitors 
and  followers  of  every  defined  event,  and  various  categories  of  fixed 
or  invariant  data.  The  data  categories  are  all  stored  together  in  the 
major  data  group  called  the  format  specifications  and  data  element  dic¬ 
tionary,  they  include  the  repertoire  of  tactical  message  formats  used 
in  all  information  flow  in  the  model,  the  dictionaries  of  permissible 
words  or  phrases  to  oe  employed  with  the  formats,  the  specification  of 
the  five  "6"  staff  elements,  rate  of  advance  tables  used  in  simulated 
engagements,  etc. 

Hard  wired  elements,  like  the  steel  and  concrete  in  a  building 
under  construction,  represent  the  underlying  structural  framework  of  the 
basic  design.  After  the  steel  framework  has  been  fully  assembled  and 
the  concrete  finally  poured,  any  modifications  or  variations  in  the 
structure  become  a  matter  of  expensive  redesign  or  retrofitting. 

SAI  believes  it  is  important  in  the  pursuit  of  any  implementation 
of  the  basic  design  to  identify  all  the  hard  wired  elements  in  the  sim¬ 
ulation  structure  and  to  document  these  elements  so  that  they  can  be 
understood  by  the  eventual  users. 

The  hard  wired  data  is  estimated  to  require  100  kilobytes  of 
data  space.  The  subgroup  organization  of  the  formats,  dictionaries,  and 
tables  has  yet  to  be  specified. 
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4. 1.3. 2  Preprocessing  Functions 


Preparation  for  an  exercise  of  the  simulation,  regardless  of 
whether  the  exercise  is  directed  toward  behavioral  research,  the  study 
of  new  tactics,  or  the  training  of  staff  officers,  will  always  have  to 
cover  three  phases  of  preprocessing  activities.  Assuming  the  design  of 
the  experiment,  the  General  Situation,  the  separate  Blue  and  Red  Special 
Situations  have  all  been  specified,  the  required  preprocessing  phases 
are  as  follows: 

•  Phase  I  -  Creation  of  the  Real  World  Data  Base: 

-  Specification  of  the  Blue  divisional  forces. 

-  Specification  of  the  Red  opposing  forces. 

-  Specification  of  the  tactical  area  and  the  deploy¬ 
ment  of  the  forces. 

•  Phase  II  -  Initialization  of  the  Blue  and  Red  Perceived 

Data  Bases: 

-  Specification  of  the  state  of  knowledge  held  by  the 
Blue  side,  consistent  with  the  research  objectives 
and  the  Blue  Special  Situation. 

-  Specification  of  the  state  of  knowledge  held  by  the 
Red  side,  consistent  with  the  research  objectives  and 
its  Special  Situation. 

•  Phase  III  -  Scenario  Event  Loading  and  Setting  the 

Control  Parameters: 

-  Specification  of  the  exogenous  trigger  events,  consis¬ 
tent  with  the  research  objectives  and  the  desired 
scenario. 

-  Adjustment  of  control  parameters  to  emphasize  special 
aspects  of  the  basic  objectives. 

-  Creation  of  the  Scenario  File. 

The  final  activity  of  Phase  III  consists  of  recording  on  a  permanent 
information  storage  medium  (magnetic  tape  or  computer  disk)  all  the  in¬ 
formation  specified  under  all  three  phases.  The  Scenario  File  then 
provides  the  basis  for  repeated  exercises  of  the  same  experiment,  carried 
out  under  identical  conditions  but  using  different  human  players. 

The  preprocessing  activities  above  will  be  the  means  for  effect¬ 
ing  the  play  of  alternative  scenarios  and  a  range  of  different  experi¬ 
ments  under  each  scenario.  The  only  constraints  imposed  will  be  the 
sizing  parameters  cited  in  the  last  subsection.  It  is  visualized  that 
the  users  of  the  integrated  simulation  will  eventually  create  and  keep 
on  file  a  number  of  different  experiment/scenario  combinations  to  be 
used  in  various  exercises  of  the  model.  The  materials  on  file  for  an 
individual  combination  would  include  the  specification  of  the  design  of 
the  experiment,  the  General  Situation,  the  Blue  and  Red  Special  Situa¬ 
tions,  and  the  magnetic  tape  Scenario  File. 
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The  use  of  a  computer  to  assist  in  the  preprocessing  activities 
would  simplify  the  task  of  setting  up  an  exercise  for  play.  The  computer 
could  take  over  entirely  the  functions  of  the  data  organization  in  the 
system  data  bases,  the  sizing  limitations,  and  the  creation  of  the  Scen¬ 
ario  Files.  The  required  phases  cited  above  suggest  a  preprocessing 
system  consisting  of  three  computer  programs,  as  illustrated  in  Figure 
4-4.  The  three  programs  could  perform  the  separate  preprocessing  func¬ 
tions  specified  for  Phase  I,  Phase  II,  and  Phase  III.  The  system,  in 
effect,  could  provide  for  the  progressive  "building"  of  the  Scenario 
File.  The  first  program  could  generate  an  output  FORCES  File  containing 
the  hard  wired  data  of  the  system  and  the  fully  developed  Real  World 
Data  Base.  The  latter  major  data  group  could  be  synthesized  by  reading 
the  input  data  which  would  contain  the  desired  Blue  and  Red  force  infor¬ 
mation.  The  second  program  could  take  the  FORCES  File  and  add  to  it  the 
initialized  forms  of  the  perceived  data  bases,  creating  thereby  its  out¬ 
put  PERFOR  File.  The  biasing  of  the  states  of  knowledge  held  by  the 
two  sides  could  be  effected  by  additional  input  data.  Finally,  the 
Phase  III  program  could  generate  the  fully  initialized  SCENARIO  File, 
based  on  the  scenario  trigger  events  and  the  control  parameter  settings 
read  from  the  input  data. 

The  preprocessing  system  would  reduce  significantly  the  time  and 
manpower  necessary  to  set  up  the  model.  Furthermore,  it  would  provide 
the  means  for  "setting  the  switches"  so  that  the  exercise  stemming  from 
the  SCENARIO  File  reflects  the  desired  research  objectives.  The  system 
of  three  computer  programs  can  be  seen  to  be  structured  to  minimize  the 
amount  of  back-tracking  necessary  to  adjust  an  experiment  to  emphasize 
different  aspects  of  the  basic  objectives.  If  the  controller/investigator 
wishes  to  replay  an  exercise  and  change  the  time  constraints  imposed  on 
a  populated  staff  module  for  its  staff  actions,  he  may  do  so  without  any 
rebuilding  of  the  SCENARIO  File.  If  he  wishes  to  modify  the  quality  of 
the  information  flowing  into  a  populated  staff  module,  he  will  be  required 
to  go  back  to  the  Phase  III  preprocessor  and  create  a  new  SCENARIO  File 
with  modified  control  parameter  settings.  If  he  wishes  to  modify  the 
initial  states  of  knowledge  of  the  Blue  and  Red  sides  in  the  simulated 
conflict,  he  will  have  to  go  back  to  the  Ph^se  II  preprocessor.  Finally, 
if  the  experiments )  is(are)  to  be  oriented  within  a  different  scenario 
using  different  compositions  of  forces,  it  will  be  necessary  to  go  back 
to  the  Phase  I  preprocessor  and  create  a  new  version  of  the  Real  World 
Data  Base. 

4. 1.3. 3  Interactive  Control  of  the  Event-Store  Simulator 

Any  exercise  of  the  battle  simulation  will  be  keyed  to  the  initial 
conditions  and  composition  of  the  forces  recorded  on  a  fully  processed 
SCENARIO  File.  The  actual  play  of  the  exercise  will  always  be  directed 
by  human  control ler(s) .  Controllers  will  be  required  not  only  to  assure 
that  the  execution  of  battle  events  as  well  as  information  flow  events 
occurs  with  the  desired  dynamic  realism  but  also  to  intervene  with  cer 
tain  of  these  events  in  order  to  influence  the  pursuit  of  thp  ba^u  nh  >  - 
ti ves . 


Figure  4-4.  The  Preprocessing  System. 


The  number  of  human  controllers,  and  the  specific  functions  they 
must  perform,  depend  on  the  kind  of  computer  assistance  they  are  given 
and  on  the  actual  procedures  followed  in  playing  populated  staff  modules. 
Accordingly,  the  basic  goals  of  a  computerized  event-store  simulator 
are  (1)  to  minimize  the  number  of  human  controllers  required,  (2)  to 
relegate  to  the  computer  all  the  more-or-less  mechanical  aspects  of  con¬ 
trolling  the  play,  and  (3)  to  facilitate  the  controller's  intervention 
so  that  he  may  effectively  apply  military  judgement  as  well  as  principles 
of  behavioral  science  during  the  play. 

In  this  framework  there  are  two  alternative  ways  the  computer 
assistance  could  be  implemented.  In  the  first  method,  controllers  would 
be  provided  with  a  large  number  of  selectable  batch-processing  computer 
programs  where  each  program  separately  accessed  the  real  world  data  base 
and  the  perceived  data  bases  on  the  SCENARIO  File.  The  individual  pro¬ 
grams  would  govern  the  execution  of  the  battle  events  and  the  staff 
input/output.  The  selection  of  the  appropriate  programs  to  run  and  the 
timing  of  the  runs  would  be  handled  manually  (by  the  controllers)  on  the 
basis  of  a  computer-printed  schedule  of  events. 

The  second  method  would  entail  a  continuously-running  event-store 
control  program  in  which  the  controllers  are  provided  with  interrupt/ 
override  controls  so  that  they  may  insert  the  decision  variables  invoked 
by  populated  staff  modules  and  intervene  with  release  events  to  influence 
the  information  flow  input  to  the  staff  players.  This  method  would  in¬ 
volve  computer  techniques  beyond  those  of  a  conventional  interactive 
program.  Once  the  simulated  battle  had  been  set  in  motion,  the  method 
would  have  to  provide  a  means  for  the  continuous  pace  of  the  battle 
events  regardless  of  the  time  of  response  reflected  by  the  staff  outputs 
from  the  populated  modules.  In  short,  the  conflict  would  continue  with 
the  combat  units  following  the  most  recently  received  operations  orders, 
until  the  engagement  was  resolved  or  until  the  staff  modules  issued  frag¬ 
mentary  orders  changing  the  course  of  the  battle. 

Both  methods  would  require  some  kind  of  clock  display  to  show 
the  controllers  and  populated  module  players  the  passage  of  simulated 
time  during  the  play.  These  clocks,  of  course,  have  to  be  geared  to  a 
real  clock  in  such  a  manner  that  the  controller(s)  could  set  the  simu¬ 
lated  clocks  so  that  they  ran  at  slow  time,  real  time,  or  fast  time 
according  to  the  basic  objectives  of  the  exercise. 

Both  methods  would  also  have  to  provide  some  kind  of  computer 
output  media  for  the  exclusive  use  of  the  controllers  so  that  the  con¬ 
trollers  could  be  kept  abreast  of  the  details  of  the  simulated  conflict 
as  it  was  reflected  in  the  real  world  data  base.  The  media  could  be 
either  an  automated  situation  map  display  or  a  printed  message  log. 

Under  the  latter  medium,  the  controllers  would  have  to  set  up  and  main¬ 
tain  their  own  situation  map  by  preparing  overlays  or  using  simple  grease 
pencil  entries  based  on  the  tactical  message  traffic  coming  out  on  the 
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message  log.  Since  the  information  on  the  situation  map  would  represent 
the  ground  truth  facts  about  the  simulated  combat,  it  would  ordinarily 
not  be  made  available  to  players  in  populated  modules. 

Finally  both  methods  must  include  the  same  logical  structure  for 
Event  No.  508,  the  fundamental  engagement  event  (see  paragraph  4.1 .2.5). 

An  engagement  event  will  always  be  associated  with  a  battle  array  entry 
in  the  real  world  data  base;  the  occurrence  of  the  event  will  determine 
(1)  whether  the  combat  engagement  is  resolved  or  continues,  (2)  the  agg¬ 
regate  force  balance  ratios  obtaining  during  the  engagement  period,  (3) 
the  losses  in  personnel,  ammunition,  equipment,  and  the  resulting  fire 
power  on  both  sides  during  the  interval,  and  (4)  the  rates  of  advance 
and  withdrawal  by  the  opposing  forces.  In  formulating  the  logical  struc¬ 
tures  for  this  event,  SAI  plans  to  make  every  effort  to  effect  the  trans¬ 
fer  of  techniques  and  to  use  lessons  learned  from  existing  battle  simu¬ 
lations.  Such  transfers  and  lessons,  however,  will  necessarily  be  inter¬ 
preted  in  the  light  of  the  differences  between  the  underlying  game  assump¬ 
tions  of  the  existing  models  and  those  adopted  here. 

Computerization  of  the  event-store  simulator,  and  the  choice 
between  the  two  methods  described  above,  clearly  depend  on  the  hardware/ 
software  resources  as  well  as  the  operating  system  ir  the  computer  faci¬ 
lities  designated  for  system  installation.  A  trade-off  also  exists 
between  the  number  of  different  functions  assigned  to  the  controllers 
and  the  facility  with  which  a  small  number  of  qualified  personnel  could 
perform  these  functions.  Any  proposed  implementation  must  specify  exactly 
the  particular  controller  functions  and  show  how  the  computer  hardware/ 
software  can  be  used  to  assist  the  controller(s)  in  carrying  out  the 
functions  without  burdening  them  with  esoteric  programming  details. 

4. 1.3. 4  Interactive  Terminal  for  Players 

If  the  integrated  battle  simulation  is  exercised  with  the  assump¬ 
tion  that  the  Blue  division  staff  elements  operate  under  a  manual  staff 
system,  the  transmission  and  receipt  of  tactical  information  by  individual 
sections  can  be  simulated  by  using  conventional  computer  input/output 
equipments.  A  populated  staff  module  will  issue  its  outputs  (Class  3 
events  or  certain  Class  2  events)  by  submitting  pencil  copy  or  typewritten 
copy  of  the  tactical  information  messages  to  the  control ler(s).  The 
control ler(s)  will  then  make  the  necessary  computer  data  entries  repre¬ 
senting  the  message  transmission  by  means  of  field  telephone,  tactical 
net  radio,  or  teletype  or  the  hand  delivery  by  courier.  The  populated 
module  will  receive  its  inputs  (Class  4  events  or  certain  Class  2  re¬ 
sponses)  by  means  of  ordinary  teletype  printers.  Individual  tactical 
information  messages  will  be  printed  with  their  standard  formats;  the 
top  line  of  the  printed  material  will  simulate  the  receipt  stamp  that  is 
always  associated  with  incoming  messages.  Successive  messages  received 
by  the  players  should  be  torn  off  as  the  players  embark  on  the  staff 
actions  associated  with  the  separate  inputs. 
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In  a  staff  system  with  field  ADP  assistance  (e.g.,  TOS),  the 
battle  simulation  will  have  to  be  expanded  to  accommodate  the  Class  6 
events  and  to  emulate  the  tactical  data  management  processes  of  the 
field  computer.  Populated  staff  modules  will  require  terminal  hardware 
beyond  that  described  above.  Using  these  enhanced  field  ADP  facilities, 
the  players  will  now  not  only  transmit  and  receive  a  large  amount  of 
their  own  tactical  message  traffic  but  also  employ  computerized  decision¬ 
making  aids  in  executing  their  staff  actions.  The  precise  role  of  the 
tactical  communications  and  the  precise  nature  of  the  algorithms  provid¬ 
ing  the  decision-making  aids  have  not  yet  been  defined,  but  it  is  known 
that  the  interactive  terminals  for  the  players  must  match  the  field 
equipment  closely  with  respect  to  the  keyboard  procedures,  the  data 
entry  language,  and  the  display  formats.  When  the  simulation  is  exer¬ 
cised  in  a  TOS  environment,  the  players  in  a  populated  staff  module 
should  see  the  same  kind  of  data  processing  equipments  and  carry  out 
the  same  procedures  that  will  ultimately  be  applied  in  the  field. 

SAI  recommends  that  the  initial  implementation  of  the  basic 
design  anticipate  insofar  as  possible  the  data  space  requirements  and 
the  added  simulation  rules  necessary  for  simulating  division  staff  sec¬ 
tions  in  the  TOS  environment,  but  that  incorporation  of  TOS-emulating 
player's  terminals  be  delayed  until  the  properties  of  the  field  termin¬ 
als  are  better  defined.  The  simulation  hardware/software  requirements 
under  a  manual  staff  system  can  be  fully  specified  at  this  time;  those 
for  an  ADP-assisted  staff  cannot. 

4. 1.3. 5  Summary  Processing 

The  last  area  for  computer  assistance  consists  of  computer  pro¬ 
grams  which  would  aggregate,  summarize,  and  format  for  printing  the 
three  classes  of  output  generated  by  the  battle  simulation.  The  pro¬ 
grams  would  accept  as  input  data  the  detailed  simulation  results  accumu¬ 
lated  on  temporary  disk  files  from  the  computerized  event-store  simula¬ 
tor.  They  would  then  summarize  and  organize  the  information  so  that 
immediate  and  assimilable  outputs  could  be  printed.  The  measures  of 
performance  of  the  Blue  Command  and  Staff  would  require  certain  statis¬ 
tical  analysis  routines.  The  measures  of  combat  outcome  would  require 
a  listing  of  the  state  variables  as  a  function  of  simulated  clock  time. 
The  record  of  Red  tactical  decisions  would  simply  be  a  printed  log  of 
the  times  and  new  initiatives  entered  by  the  Red  side. 

The  software  development  costs  of  these  programs  would  be  modest, 
once  the  basic  system  design  and  the  computerized  event-store  simulator 
have  been  implemented. 

The  benefits  associated  with  providing  immediate  printed  results 
following  an  exercise  on  the  battle  simulation  appear  significant. 
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PROPOSED  INITIAL  IMPLEMENTATION 


This  subsection  presents  the  key  elements  of  the  proposed  initial 
implementation.  The  preceding  discussion  of  the  basic  design  concept 
pictured  a  system  with  six  "plug-in"  modules.  Five  of  these  modules 
represent  separately  the  Blue  Division  Command  Group  and  its  four  prin¬ 
cipal  staff  sections;  the  sixth  module  is  the  Red  Command.  The  system 
provides  for  the  play  of  a  division-level  war  game  in  which  the  confi¬ 
guration  of  play,  that  is,  the  combination  of  populated  modules  and 
simulated  modules  among  the  six,  can  be  selected.  The  play  involves  not 
only  the  simulated  combat  between  the  opposing  forces  but  also  the  vary¬ 
ing  states  of  knowledge  the  opposing  commanders  use  as  the  basis  for 
their  tactical  decisions.  The  system  handles  the  information  flow  of 
approximately  75  different  kinds  of  tactical  messages  between  the  command 
elements  and  the  combat  units  and  provides  the  realistic  time  sequencing 
of  approximately  350  different  kinds  of  defined  events,  covering  the 
staff  actions,  staff  coordination,  staff  output,  and  staff  input,  as 
well  as  the  simulated  battle  occurrences.  The  concept  defines  a  general 
interactive  war  game  simulation  of  sufficient  scope  and  flexibility  that 
can  be  applied  alternatively  to  behavioral  research,  the  development  and 
evaluation  of  new  tactics,  or  the  training  of  staff  personnel. 

The  proposed  implementation  of  this  design  is  predicted  on  a 
system  that  can  be  di rected  and  operated  by  one,  or  a  most,  two  human 
controllers.  As  stated  in  the  earlier  discussion,  the  specification  of 
controller  functions  must  be  made  in  the  framework  of  the  actual  proce¬ 
dures  used  in  the  play  of  the  populated  modules  and  the  specific  kinds 
of  computer  assistance  the  controllers  are  provided  with.  That  specifi¬ 
cation  is  given  below. 

The  proposed  implementation  will  impose  a  constraint  on  the  num¬ 
ber  of  populated  modules  played  in  one  exercise.  The  basic  design  stipu¬ 
lated  that  any  combination  of  the  "plug-in"  modules  could  be  selected 
(see  Table  4-1).  This  means  that  the  number  of  populated  modules  can 
vary  from  zero  up  to  six.  Since  each  populated  module  implies  certain 
minimum  computer  hardware/software  requirements  as  well  as  a  proportion¬ 
ate  work  load  imposed  on  the  controllers,  the  system  will  therefore  be 
limited  to  no  more  than  two  1 i ve  staff  modules  in  the  initial  proposed 
implementation.  The  selected  modules  may  be  any  two  out  of  six,  but  in 
no  case  may  the  total  exceed  two.  This  constraint  limits  the  configura¬ 
tions  of  play  to  22  out  of  the  64  alternative  choices  shown  in  Table  4-1. 

The  proposed  implementation  will  be  further  constrained  at  this 
time  to  the  exercise  of  Blue  staff  modules  operating  under  a  manual  staff 
system  only.  It  was  shown  in  the  preceding  subsection  that  an  inter¬ 
active  simulation  of  a  division  staff  in  a  TOS  environment  required  not 
only  expanded  logical  rules  covering  the  decision-making  aids  provided 
by  the  field  computer  but  also  interactive  terminals  for  the  players  in 
populated  modules.  The  latter  hardware  requirement,  furthermore,  had 


to  be  a  reasonable  match  with  the  actual  field  terminals  with  respect  to 
the  keyboard  procedures,  the  data  entry  language,  and  display  formats. 

It  is  proposed,  therefore,  that  the  implementation  of  ADP-assisted  staffs 
be  deferred  until  the  tactical  data  management  functions  and  the  staff 
procedures  are  better  defined. 

The  key  elements  of  the  initial  implementation  are  now  described 
in  the  framework  of  these  specific  constraints.  The  description  begins 
with  the  proposed  physical  layout  of  a  system  involving  one  or  two  popu¬ 
lated  modules  and  run  by  one  or  two  controllers.  Under  this  proposed 
architecture,  the  basic  procedures  for  playing  live  staff  modules  are 
outlined.  The  description  then  continues  with  the  key  element,  the 
specification  of  the  controller  functions.  The  role  of  the  controllers 
is  defined  both  for  setting  up  an  exercise  for  play  and  for  controlling 
the  exercise  after  the  simulated  clock  starts  running.  The  discussion 
is  concluded  with  description  of  the  computer  programs  that  will  consti¬ 
tute  the  preprocessing  system,  and  of  the  interactive  executive  control 
routine  that  will  provide  the  basis  for  the  controller's  functions  dur¬ 
ing  the  play. 

4-2.1  Physical  Layout  for  Two  Populated  Modules 

The  proposed  physical  layout  for  the  integrated  battle  simulation 
is  shown  in  Figure  4-5.  The  figure  gives  the  basic  floor  plan  for  the 
system  if  the  simulation  were  configured  for  a  populated  Blue  G2  Staff 
Module  and  a  populated  Red  Command  Module.* 

The  layout  requires  that  the  controller(s)  and  the  populated 
player  modules  (as  well  as  the  computer  main  frame)  occupy  separate 
rooms  during  the  play.  The  transactions  and  communications  between  the 
controller(s)  and  the  player  modules  will  be  confined  to  exchanges  of 
hand  written  or  printed  tactical  information  messages  or  documents  passed 
through  the  Dutch  door  access  windows.  Oral  exchanges  will  be  permitted 
only  if  initiated  by  the  controller(s)  during  a  period  when  the  simulated 
clock  is  not  running.  The  display  materials  in  the  controller's  room: 
the  controller's  situation  map,  the  printed  message  log,  and  the  cathode 
ray  tube  (CRT)  screens  should  be  shielded  from  the  players  so  that  the 
players  cannot  "cheat"  by  getting  access  to  the  real  world  data. 

The  basic  method  of  play  will  be  as  follows:  The  staff  person¬ 
nel  will  execute  the  appropriate  staff  actions,  where  required,  and  ini¬ 
tiate  staff  outputs  (Class  3  events  or  certain  Class  2  queries,  respon¬ 
ses,  or  requests)  by  passing  pencil  copies  or  typewritten  copies  of  the 
tactical  messages  through  the  access  windows  to  the  control ler(s).  The 
submission  of  the  hard  copy  in  this  manner  will  represent  the  staff 
section  directing  its  radio  telephone  operator  (RTO)  to  transmit  or  dis¬ 
patch  the  output.  The  control ler(s) ,  in  turn,  will  effect  the  actual 


*This  corresponds  to  Configuration  No.  36,  as  listed  in  Table  4-1. 


Figure  4-5.  Proposed  Physical  Layout. 


r 


transmissions  by  making  message  data  entries  on  the  controllers  keyboard. 
The  staff  personnel  will  receive  its  staff  inputs  (Class  4  events  or 
certain  Class  2  responses  or  information  copies)  by  means  of  medium 
speed*  teletype  printers  located  in  their  separate  rooms.  The  messages 
will  be  printed  out  in  the  standard  tactical  message  formats.  The  top 
line  of  each  communication  received  will  contain  a  representation  of  the 
receipt  stamp  associated  with  the  incoming  message.  It  will  show  the 
data-time  group  of  the  moment  the  message  is  being  printed.  The  receipt 
of  staff  inputs  will  provide  some,  but  not  all,  of  the  basic  triggers 
for  the  different  staff  actions.  The  staff  personnel  should  tear  off 
the  printed  messages  as  they  are  received  prior  to  embarking  on  those 
actions. 

It  will  be  shown  that  the-  control ler(s )  will  have  a  continuous 
display  of  the  running  simulated  date-time-group  at  the  top  of  their 
CRT.  This  will  provide  the  controller(s)  with  a  simulated  clock.  The 
players  in  the  staff  module  rooms,  on  the  other  hand,  will  be  required 
to  judge  the  passage  of  simulated  time  by  noting  the  times  received  on 
the  successive  input  messages  coming  in  on  the  teletype  printers.  These 
times  will  be  geared  to  the  simulated  clock  in  the  computer.  Of  course, 
if  the  exercise  itself  is  geared  to  real  time  (i.e.,  the  speed  ratio  is 
set  at  1.0),  then  the  players  may  synchronize  their  own  watches  and  wall 
clocks  to  match  the  clock  settings  of  the  messages. 

It  should  be  noted  that  the  proposed  physical  layout  will  provide 
the  necessary  computer  hardware  so  that  the  simulation  may  be  adapted 
to  any  of  the  22  permissible  configuration  of  play.**  Although  Figure 
4-5  illustrates  a  system  configured  for  a  live  Blue  G2  Section  and  a 
live  Red  Command,  the  layout  could  be  modified  simply  by  rearranging 
the  furnishing  and  materials  in  the  player  module  rooms  so  that  the  al¬ 
ternative  staff  modules  had  their  necessary  staff  equipments.  The  tele¬ 
type  printers  would  remain  as  shown  except  that  their  umbilical  connec¬ 
tors  to  the  computer  might  have  to  be  interchanged. 

4.2.2  Controller  Functions 


The  proposed  implementation  focusses  on  a  system  requiring  one, 
or  at  most,  two  human  controllers  to  set  up  and  run  exercises  in  simu¬ 
lated  division-level  combat.  It  will  be  seen  that  the  proposed  computer 
assistance  is  oriented  to  the  specific  controller  functions  in  ways  that 
will  make  the  running  of  exercises  entirely  manageable  by  only  one  or 
two  qualified  personnel. 

The  key  element  here  is  the  identification  of  all  functions  to 
be  assigned  to  controllers.  Preparation  for  an  exercise  will  require 


*300  baud. 

**The  permissible  configurations  of  play  are  those  involving  at  most  two 
populated  modules.  See  Table  4-1. 
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not  only  one  or  more  phases  of  preprocessing  activities  (as  described  in 
paragraph  4. 1.3. 2)  but  also  the  creation  of  the  controller's  situation 
map  and  the  preparation  and  organization  of  a  set  of  documents  to  be 
handed  out  to  players  later  during  the  exercise.  After  the  simulated 
clock  starts  running,  the  actual  play  of  the  exercise  will  require  the 
keyboard  entry  of  staff  outputs,  keyboard  intervention  on  certain  release 
events,  maintenance  of  the  real  world  situation  map,  and  the  passing  of 
the  documents  to  the  players  according  to  the  basic  schedule  of  events. 

The  specification  of  controller  functions  and  ways  the  computer 
will  facilitate  their  performance  are  presented  below. 

4.2.2. 1  Preparatory  Functions 

Every  individual  exercise  of  the  battle  simulation  will  be  rooted 
to  a  unique  set  of  materials  consisting  of  the  design  of  the  experiment, 
the  General  Situation,  the  separate  Blue  and  Red  Special  Situations,  and 
the  magnetic  tape  SCENARIO  File.  The  documents  will  specify  the  basic 
research  objectives  and  the  scenario  for  the  exercise;  the  magnetic 
tape  will  contain  data  and  control  parameter  settings  consistent  with 
these  stated  objectives  and  tactical  setting.  If  the  SCENARIO  File  has 
been  fully  processed,  the  materials  will  also  include  computer  listings 
stemming  from  the  preprocessing  system.  Furthermore,  if  the  exercise 
has  already  been  played,  the  materials  might  also  include  controller 
map  overlays  that  were  developed  during  the  earlier  run. 

The  controller  functions  in  preparing  for  the  exercise  are  orien¬ 
ted  to  this  collection  of  materials.  Starting  with  a  complete  or  partial 
set,  the  controller(s)  must  perform  the  following  preparatory  functions: 

•  Generation  of  the  completed  form  of  the  SCENARIO  File 
and  the  accompanying  computer  listings. 

t  Validation  that  the  stated  objectives  and  the  tactical 
situation  are  reflected  in  the  computer  listings. 

•  Creation  of  the  real  world  situation  map  based  on  the 
computer  listings. 

t  Organization  of  those  tacti cal  documents  to  be  used  in 
the  play  into  chronological  files  by  staff  section. 

It  should  be  noted  that  the  first  function  involves  the  running  of  the 
computer  preprocessing  system  and  that  the  remaining  functions  are 
wholly  dependent  on  the  computer  listings  stemming  from  the  system. 
Although  the  preparatory,  functions  will  not  require  direct  interactions 
with  the  computer,  controllers )  should  be  familiar  with  the  basic  data 
card  formats  and  card  punch  procedures  used  in  the  preprocessing  system 
and  should  be  able  to  assimilate  quickly  the  printed  information  on  the 
listings. 


4-42 


The  basic  structure  of  the  proposed  preprocessing  system  is  that 
described  in  paragraph  4. 1.3. 2.  This  structure  provides,  through  its 
technique  of  progressively  building  the  SCENARIO  File,  a  flexible  means 
for  executing  the  first  preparatory  function.  The  separate  printed 
listings  coming  from  the  Phase  I,  Phase  II,  and  Phase  III  Preprocessing 
Programs  will  cover,  respectively,  the  Red  and  Blue  force  tables,  the 
initial  states  of  knowledge  held  by  the  two  sides,  and  the  exogenous 
events  and  parameter  settings  for  the  exercise.  These  listings,  and 
the  intermediate  magnetic  tape  files,  together  will  provide  a  basis  for 
generating  new  or  modified  experiment/scenario  combinations  quickly, 
usually  without  requiring  a  complete  repetition  of  the  entire  synthesis 
process. 


It  should  be  recognized,  however,  that  the  logical  detail  exhi¬ 
bited  by  the  force  tables,  the  state  of  knowledge  tables,  and  the  para¬ 
meter  settings  will  be  complex  in  aggregate  and  will  require  that  the 
controller(s)  possess  a  reasonable  understanding  of  the  overall  model 
operation. 

4. 2. 2. 2  Control  Functions 

After  the  stage  has  been  set  for  an  exercise,  control ler(s)  will 
run  the  game  using  the  basic  facilities  in  the  controller's  room,  as 
illustrated  in  Figure  4-5.  He  (they)  will  be  required  to  carry  out  the 
following  specific  control  functions,  guided  by  the  displays  on  the  CRT 
and  the  printed  material  on  the  computer  message  log: 

•  Starting  and  stopping  the  simulated  clock. 

•  Keyboard  data  entry  of  staff  outputs  submitted  by  staff 
players. 

•  Maintenance  of  the  controller's  situation  map,  as  the 
simulated  combat  progresses. 

•  Keyboard  data  entry  and  execution  of  certain  release 
events.  Release  events  will  be  explained  further  below. 

•  Logging  in/out  tactical  documents  transmitted/ received 
by  the  player  modules,  but  not  involved  directly  in  the 
simulated  battle. 

These  functions  are  all  tied  to  the  proposed  interactive  executive  con¬ 
trol  routine  in  which  the  computer  will  control  the  time  sequencing  of 
battle  events  as  well  as  govern  the  flow  of  tactical  information  to  and 
from  the  populated  staff  modules. 

The  controller(s)  will  initiate  the  routine  (but  not  the  simu¬ 
lated  clock)  by  means  of  a  simple  keyboard  call.  This  call  will  evoke 
a  basic  control  screen  display  on  the  CRT  and  print  header  lines  on  the 
controller's  message  log  as  well  as  on  the  teletype  printers  in  the 
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player  module  rooms.  The  control  screen  display,  which  will  be  the  point 
of  departure  for,  and  the  general  basis  of,  the  control ler(s)  functions 
during  the  play,  is  shown  in  Figure  4-6. 

A  more  detailed  discussion  of  the  specific  control  functions  is 
given  below.  At  this  point,  however,  a  few  explanatory  remarks  are  in¬ 
jected  about  the  controller's  basic  display  shown  in  the  figure.  It 
should  be  said  first  that  the  basic  display  is  just  one  out  of  many 
different  formatted  screens  the  controllers  will  see  during  the  course 
of  play.  It  will  be  shown  that  while  executing  their  control  functions, 
the  controller(s)  will  cause  the  CRT  to  switch  back  and  forth  between  a 
number  of  different  displays  depending  on  the  specific  functions  they 
are  addressing.  All  screens,  however,  will  contain  the  same  three  top 
lines  as  those  shown- in  the  figure.  These  lines  will  display  continu¬ 
ously  the  following  basic  items  of  information  about  the  exercise: 

•  The  name  of  the  scenario  exercise. 

•  The  current  data-time-group  (DTG)  in  the  simulation. 

•  The  selected  configuration  of  play. 

•  The  simulated  clock  status  indicator. 

•  The  speed  ratio  setting  in  the  simulation. 

The  computer  will  initialize  the  items  from  data  in  the  SCENARIO  File. 

After  the  simulated  clock  is  set  running,  the  clock  status  indicator 
will  change  and  the  DTG  will  tick  off  the  minutes  of  simulated  time. 

Starting/Stopping  the  Simulation.  The  controller(s)  will  exe¬ 
cute  control  of  the  simulated  clock  by  means  of  control  options  (1)  and 
(5)  on  the  controller's  basic  display.  Whenever  the  clock  status  indi¬ 
cator  states  that  the  clock  is  not  running,  the  man  at  the  terminal 
keyboard  may  start  the  clock  by  keying  the  digit  "1"  followed  by  a  space 
and  then  either  the  word  "END"  or  else  the  clock  reading  he  desired  for 
the  next  stop.  Similarly,  when  the  clock  is  running,  the  controller 
may  stop  it  simply  by  keying  the  digit  "5",  notwithstanding  the  previously 
entered  stopping  time. 

Whenever  the  simulated  clock  is  inert,  the  control ler(s )  may 
also  modify  the  simulation  speed  ratio  or  even  the  configuration  of 
play  by  invoking  control  option  (6). 

The  whole  system  may  be  shut  down  by  control  option  (7). 

Keyboard  Entry  of  Staff  Outputs.  The  architecture  of  the  pro¬ 
posed  implementation  is  based  in  part  on  the  idea  that  staff  outputs  - 
including  the  initiation  of  coordination  exchanges  with  other  elements 
-  are  "transmi tted"  by  the  players'  passing  hardcopy  messages  through 
the  access  windows  to  the  controller(s) .  The  control ler(s) ,  in  turn, 
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Figure  4-6.  The  Controller's  Basic  Display. 


must  bring  about  the  transmissions  by  making  keyboard  data  entries  on 
their  terminal.  The  key-in  procedures  for  these  orders,  queries,  re¬ 
sponses,  and  tactical  reports  will  be  of  two  kinds,  depending  on  whether 
the  message  contains  basic  decision  variables  affecting  the  simulated 
battle  or  is  merely  a  tactical  document  to  be  issued  by  the  populated 
staff  module,  but  not  otherwise  involved  in  the  combat  simulation.  In 
the  first  procedure,  the  controller(s)  must  key  in  the  whole  message 
through  the  use  of  a  lexicon  of  special  abbreviations  and  symbols  that 
will  be  provided.  In  the  latter  case,  the  control ler(s)  must  simply  log 
in  the  document  by  keying  in  a  short  combination  of  letters  and  digits 
that  post  the  log  entry. 

The  controller(s)  may  initiate  the  tactical  message  data  entry 
function  by  invoking  control  option  (2)  on  the  basic  screen.  The  ter¬ 
minal  operator  may  select  this  option  whether  the  simulated  clock  is 
running  or  not.  He  must  key  in  the  digit  "2"  followed  by  a  space  and 
then  a  three-digit  designator  which  specifies  the  type  message  he  wishes 
to  enter.  The  keyboard  selection  will  cause  the  control  screen  to  dis¬ 
appear  and  be  replaced  by  a  different  screen  format.  The  new  display 
will  provide  the  basis  for  the  controller  to  key  in  the  message.  When 
the  message  has  been  fully  entered,  its  transmission  will  then  be  trig¬ 
gered  by  a  special  key,  following  which  the  message  format  screen  will 
disappear  and  the  controllers  basic  display  will  return. 

Maintenance  of  the  Controller's  Situation  Map.  The  real  world 
situation  map,  along  with  the  controller's  message  log,  will  be  the 
principal  means  for  observing  the  unfolding  battle  outcomes  resulting 
from  the  opposing  commander's  decisions.  Controller(s)  will  maintain 
this  situation  map  during  the  play. 

As  will  be  shown  in  the  discussion  on  release  events,  the  con¬ 
trol  ler(s)  will  not  only  update  the  map  from  information  presented  to 
them  by  the  computer  but  also  use  the  map  to  assist  them  in  feeding 
subsequent  intervention  data  back  into  the  computer.  Practiced  con¬ 
trollers  will  probably  develop  their  own  shortcut  techniques  for  this 
purpose,  using  perhaps  grease  pencil  entries  for  certain  kinds  of  in¬ 
termediate  battle  events  and  multiple  map  overlays  for  different  periods 
of  simulated  combat. 

Controller  Intervention.  In  the  play  of  an  exercise,  the  tacti¬ 
cal  decisions  imposed  by  the  controller  in  order  to  influence  the  basic 
research  objectives,  the  battle  events  in  which  the  controller  must  in¬ 
tervene  with  military  judgement,  and  the  arrivals  of  certain  tactical 
documents  from  higher  headquarters  to  the  populated  staff  sections  are 
all  called  release  events.  A  release  event  is  any  event  in  the  simula¬ 
tion  whose  execution  depends  on  controller  intervention.  The  interven¬ 
tion,  furthermore,  should  be  completed  on  or  before  the  time  of  the 
event,  as  measured  by  the  simulated  clock.  Release  events  will  be 
generated  and  scheduled  for  occurrence  in  the  event-store  simulator 
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about  five  to  twenty  minutes  (in  simulated  time)  before  they  actually 
occur.  The  control ler(s),  having  been  warned  of  the  forthcoming  release, 
must  effect  their  intervention  during  this  short  interval. 

Controller(s)  will  handle  release  events  by  means  of  control 
options  (3)  and  (4)  in  the  basic  display.  At  the  time  a  release  event 
is  first  generated,  the  screen  will  post  a  warning  to  the  controller(s) 
by  incrementing  the  "release  queue  number,"  which  is  the  number  exhibited 
in  parentheses  in  the  middle  of  the  text  in  control  option  (3).  If  the 
release  queue  number  is  zero  (as  illustrated),  the  controller(s)  will  be 
apprised  that  no  release  events  will  be  currently  forthcoming;  if  the 
queue  is  1  or  more,  they  will  be  alerted  to  the  fact  that  one  or  more 
interventions  will  be  required  within  the  next  few  minutes  of  simulated 
combat. 


If  the  terminal  operator  selects  control  option  (3)  by  keying 
in  the  digit  "3,"  the  basic  control  screen  will  disappear  and  a  new  dis¬ 
play  will  present  the  list  of  forthcoming  release  events.  The  list  will 
be  arranged  so  that  earliest  forthcoming  event  appears  at  the  top.  The 
entries  in  the  list  will  not  only  indicate  the  time  of  occurrence  but 
also  identify  the  type  of  intervention  required.  After  the  control ler(s) 
have  reviewed  the  queue,  the  operator  may  then  erase  the  display  and 
return  to  the  controller's  basic  screen  by  pressing  a  single  key. 

If  a  controller  selects  control  option  (4),  the  computer  will 
automatically  institute  the  associated  display  format  required  to  effect 
the  intervention  of  the  first  (earliest)  release  event.  The  new  screens 
will  involve  either  simple  keyboard  instructions  or  complicated  data 
entry  procedures,  depending  on  the  type  of  intervention  being  addressed. 
After  the  control ler(s )  have  executed  the  instructions  or  procedures, 
the  special  screens  will  disappear  and  the  basic  display  will  return 
to  the  CRT. 

Release  events  associated  with  the  arrival  of  tactical  documents 
from  corps  headquarters  or  from  adjacent  divisions  will  involve  only 
simple  mechanical  tasks  on  the  part  of  the  controller(s) .  At  the  time 
indicated  for  the  event  occurrence,  the  control ler(s)  must  pass  the 
documents  through  access  windows  to  players  in  the  staff  module  rooms. 
These  actions  are  essentially  the  reverse  of  the  procedures  cited  above 
for  the  keyboard  entry  of  staff  outputs. 

Release  events  for  imposing  tactical  decisions  or  supplementing 
the  battle  event  logic,  on  the  other  hand,  will  require  evaluation  of 
the  situation  at  hand  and  keeping  in  mind  the  basic  objectives  of  the 
exercise.  They  will  also  entail  keyboard  data  entry  of  more  elaborate 
scope  than  that  implied  above.  These  types  of  release  events  are  de¬ 
veloped  further  in  paragraph  4.3.6. 
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Logging  of  Tactical  Documents.  The  last  control  function  assig¬ 
ned  to  the  control ler(s)  has  been  shown  to  be  subsumed  in  the  procedures 
for  keyboard  entry  of  staff  outputs  and  the  controller  intervention  per¬ 
taining  to  tactical  document  arrivals. 

4.2.3  What  the  Computer  Mill  Do 

The  final  key  element  of  the  initial  implementaion  is  the  com¬ 
puter  assistance  proposed  to  facilitate  setting  up  and  running  the  battle 
simulation.  The  physical  layout  and  specification  of  the  controller  func¬ 
tions  set  forth  in  the  preceding  paragraphs  make  reference  to,  and  are 
based  on,  specific  computer  hardware  components  and  a  fundamental  com¬ 
puter  program  structure  for  the  software.  The  proposed  computer  programs 
consist  of  the  three  routines  of  the  preprocessing  system  and  a  single 
interactive  executive  control  routine  ( I ECR) . 

The  preprocessing  system  has  already  been  described.  The  manner 
in  which  the  three  preprocessors  will  provide  for  the  organization  of 
simulation  data  was  presented  in  paragraph  4. 1.3. 2,  and  the  ways  the 
control ler(s)  will  be  assisted  by  the  system  were  shown  in  paragraph 
4. 2. 2.1.  The  required  elements  for  programming  the  system  are  not  pur¬ 
sued  further  at  this  point  but  will  be  developed  later  in  the  next  sub¬ 
section. 

The  IECR,  on  the  other  hand,  will  be  the  basis  for  running  the 
event-store  simulator  with  a  controllable  simulated  clock  such  that  the 
control ler(s)  may  execute  their  control  functions  without  destroying 
the  dynamic  realism  of  the  model.  The  IECR  represents  the  second  of  the 
two  approaches  outlined  in  paragraph  4. 1.3. 3.  It  will  provide  for  the 
simultaneous  time  sequencing  of  the  combat  events,  the  staff  input/output 
events,  and  the  keyboard  data  entry  implicit  in  the  controller's  inter¬ 
vention;  it  will  contain  a  software  mechanism  called  an  asynchronous 
trap  which  will  accommodate  this  simultaneous  dynamic  portrayal  of  the 
on-going  battle  and  injection  of  orders,  queries,  and  controller's 
release  events. 

In  pursuit  of  Subtask  1.6  of  the  basic  top-down  design,  SAI  using 
a  part  of  its  uncompensated  efforts,  has  programmed  and  tested  a  skeletal 
interactive  control  system  operable  on  a  PDP-11  computer.*  This  routine 
has  demonstrated  successfully  not  only  the  operation  of  the  asynchronous 
trap  but  also  the  automatic  switching  required  for  playing  alternative 
configuration  numbers.  As  a  first  stage  test  program  the  system  merely 
emulates  the  event-store  mechanism  through  a  simple  four-event  scenario, 


*SAI's  computer  routine  is  called  Tactical  Information  Exchange  in  a 
Division-Level  Exercise  (TIEDE).  The  program  is  evoked  by  the  keyboard 
instruction  "CALL  TIEDE."  Explanatory  footnote  by  2nd  and  3rd  authors 
without  the  permission  of  the  1st  author. 
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but  it  has  shown  that  the  simulation  can  be  geared  to  any  reasonable 
speed  ratio,  giving  slow  time,  real  time,  or  fast  time  play  as  desired. 

The  interactive  aspects  of  the  proposed  IECR  were  described  in 
some  detail  in  the  preceding  paragraph.  A  broader  perspective  on  the 
war  game  simulation  as  a  whole  is  now  presented  by  showing,  first,  how 
the  IECR  will  provide  staff  element  players  with  their  staff  inputs 
during  an  exercise,  and  second,  how  it  will  generate  at  the  same  time 
the  battle  event  entries  on  the  controller's  message  log.  The  perspec¬ 
tive  is  based  on  a  hypothetical  scenario  in  which  V  (US)  Corps  is  attacked 
by  Warsaw  Pact  forces  as  part  of  a  general  Pact  attack  in  Central  Europe. 
The  division  level  exercise  is  assumed  to  be  configured  for  a  populated 
Blue  G2  Staff  Module  and  to  begin  at  0430  hours  on  1  August  1982. 

4.2. 3.1  Staff  Inputs  Received  on  the  Teletype  Printer 

During  the  first  twenty  minutes  of  simulated  time,  the  Intelli¬ 
gence  Staff  players  will  receive  the  staff  inputs  shown  in  Figure  4-7. 

The  figure  illustrates  four  basic  entries  printed  on  teletype  paper. 

The  first  entry  is  simply  the  one-line  notification  to  the  players  that 
the  simulated  clock  in  the  exercise  has  begun  running.  The  remaining 
entries  are  individual  input  tactical  information  messages  that  will  spur 
the  staff  players  to  initiate  the  appropriate  actions.  The  messages 
will  be  printed  at  different  moments  in  simulated  time,  so  that  the 
players  will  "receive"  the  messages  at  0437,  0438,  and  0448  hours,  re¬ 
spectively,  as  shown  by  the  top  line  receipt  stamp  representations. 

The  messages  are  spaced  on  the  paper  so  that  each  successive  trigger 
may  be  torn  off  to  be  used  as  the  basis  for  the  staff  action  associated 
with  it. 


The  three  messages  shown  illustrate  three  of  the  many  different 
types  of  formats  to  be  used  in  the  IECR. 

The  first  input  is  a  copy  of  the  combat  intelligence  report  filed 
by  elements  of  the  covering  force  after  initial  contact.  This  type 
message  (Event  No.  444)  is  a  tactical  information  document  which  is  pre¬ 
pared  beforehand  as  typewritten  copy  and  passed  to  the  players  as  the 
result  of  a  release  event  execution  by  the  control ler(s) .  Although  the 
G2  staff  must  initiate  the  appropriate  action,  the  contents  of  the  re¬ 
port  have  no  direct  bearing  on  the  simulated  combat  events. 

The  second  input  is  an  information  copy  of  an  air  defense  warn¬ 
ing  order  issued  by  the  (simulated)  G3.  The  message  type  (Event  No. 

255)  is  a  Class  2  event  stemming  from  actions  by  the  operations  staff. 
Receipt  of  this  message  reflects  the  standard  procedures  that  all  staff 
elements  are  sent  information  copies  of  fragmentary  orders  or  warning 
orders  issued  by  the  cognizant  sections. 
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INPUT  MESSAGES  TO  BLUE  G?  STATE  SECTION 


SO 104 30 

AUG  1932 

SIMULATED  CLOCK  BEGINS  RUNNING. 

SO 104 36 

AUG  1982 

RECEIVED  BY  BLUE  G2  STAFF  SECTION. 

1010421 

AUG  1982 

UNCLASSIFIED 

FROM: 

5 3RD  ACR 

TO: 

CG,  V  CORPS 

INFO: 

23R0  OIV,  62ND  DIV,  37TH  DIV 

TYPE 

REPORT: 

COMBAT  INTELLIGENCE  REPORT 

(PICK  UP  OOCUMENT  AT  THE' WINDOW) 


S010438  AUG  1982  RECEIVED  BY  BLUE  G2  STAFF  SECTION. 

E010437  AUG  1982  U.N  C  L  A  S  S  I  f  I  E  D  (255) 


FROM 

CG.  62 NO  DIV/G3 

TO: 

2ND  BOE 

INFO: 

TYPE 

REPORT: 

AIR  DEFENSE  WARNING 

1. 

WARNING: 

RED 

2. 

OIR  ATTK: 

NE 

3. 

SIZE  ATTK: 

FEW 

4. 

PRED  TGT: 

2ND  BDE 

S010448 

AUG 

1982 

RECEIVED  BY  BLUE  G2  STAFF  SECTION 

1010443 

AUG 

1982 

U-.N  C  L  A  S  S  1  F  I  E  D 

FROM: 

ASAC 

TO: 

CG,  62ND  DIV/G2 

INFO: 

TYPE 

REPORT: 

COMBAT  INTELLIGENCE  REPORT 

(444) 


1. 

TIME: 

010350  AUG 

2. 

LOCATION: 

NA78329640 

3, 

DIR  MVMT : 

WSW 

4. 

RATE  MVMT: 

5  KPH 

5. 

UNIT  SIZE: 

COMPANY 

6. 

UNIT  TYPE: 

INF 

7. 

QTY  TANKS: 

NA 

8. 

QTY  APCS: 

NA 

9. 

ARTY  TU8ES: 

NA 

10. 

UNK  VEHS: 

NA 

11. 

QTY  TROOPS: 

125 

Figure  4-7.  Staff  Inputs  Keceived  on  the  Teletype  Printer. 
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The  last  input  shown  for  the  G2  element  is  another  combat  intel¬ 
ligence  report,  this  one  coming  from  the  division  all -source  analysis 
center.  An  enemy  LRRP  has  been  discovered  as  the  result  of  a  fire  fight 
in  the  3rd  Brigade  area.  This  message  (Event  No.  444)  has  been  generated 
as  the  result  of  a  whole  sequence  of  battle  events  that  has  occurred  in 
the  BOG. 

It  should  be  noted  that  after  twenty  minutes  of  play  the  sum 
total  of  the  information  on  the  enemy  order  of  battle  and  dispositions 
held  by  G2  element  will  be  reflected  in  the  EOB  chart,  the  ENSIT  map, 
and  the  various  element  files  as  these  things  have  been  modified  by  the 
content  of  the  three  input  messages. 

4. 2. 3. 2  Controller's  Message  Log 

During  the  same  twenty  minute  period  of  simulated  time,  the  high¬ 
speed  printer  in  the  controller's  room  will  be  listing  the  entries  of 
the  message  log,  as  illustrated  in  Figure  4-8.  The  listing  shows  ten 
significant  events  about  the  unfolding  simulated  combat.  The  IECR  will 
have  processed  the  occurrence  of  as  many  as  100  to  200  events  during 
the  simulated  period,  but  the  message  log  will  exhibit  only  those  events 
that  are  relevant  to,  and  necessary  for,  the  control  of  the  exercise  or 
the  analysis  of  the  results  afterwards.  A  brief  description  of  these 
relevant  entries  follows. 

The  first  entry  is  simply  the  one-line  notification  that  the 
simulated  clock  has  started  running. 

The  second  entry,  which  will  be  printed  after  two  minutes  of 
simulated  time,  records  the  receipt  of  a  staff  input  by  a  section  that 
is  simulated. 

The  third  entry,  printed  at  0436  hours,  records  the  receipt  by 
the  live  G2  players  of  the  copy  of  the  combat  intelligence  report  from 
the  covering  force  to  corps.  This  entry  represents  a  release  event 
that  has  already  been  executed  by  the  controller(s) ,  as  described  in 
the  preceding  paragraphs.  At  the  time  the  entry  is  printed,  the  con¬ 
trollers)  will  transfer  the  typewritten  document  from  their  files  to 
the  players. 

The  fourth  entry,  printed  after  seven  minutes  of  play,  is  the 
first  significant  evidence  to  the  controller(s)  of  the  progress  of  the 
Warsaw  Pact  attack.  The  entry  provides  a  basis  for  the  control ler(s) 
to  address  their  situation  map  in  anticipation  of  the  imminent  engage¬ 
ment  between  Blue  and  Red  forces. 

The  fifth  entry  will  be  printed  at  the  same  time  as  the  fourth. 
This  entry  apprises  the  control ler(s)  that  a  simulated  staff  element  has 
initiated  an  action  pertinent  to  the  developing  conflict. 


4-51 


CONTROLLERS  MESSAGE  LOG 


S010430 

AUG  1982 

SIMULATEO  CLOCK  BEGINS  RUNNING. 

$0104 32 

AUG  1982 

BLUE  G3  SECTION  RECEIVED  AIR  DEFENSE  ALERT 

(464) 

S010436 

AUG  1982 

RECEIVED  BY  BLUE  G2  STAFF  SECTION. 

FO 10421 

AUG  1982 

UNCLASSIFIED 

(444) 

FROM: 

53RD  ACR 

TO: 

CG.  V  CORPS 

INFO: 

23RD  DIV.  62 NO  DIV,  37TH  DIV 

TYPE  REPORT: 

COMBAT  INTELLIGENCE  REPORT 

(RELEASE  OOCUMENT  TO  PLAYERS) 

S010437 

AUG  1982 

RED  AIRMOBILE  ELEMS  623  MRR  LAND  VIC  NA69409930. 

SOI 0437 

AUG  1982 

BLUE  G3  SECTION  ISSUES  AD  URNG  ORDER  001 

(355) 

S010439 

AUG  1982 

RED  AIRMOBILE  ELEMS  623  MRR  LAND  VIC  NA69429925 

S010445 

AUG  1982 

ENGAGEMENT  PHASE  (J;  BATTLE  ARRAY  0001. 

SOI  0448 

AUG  1982 

RECE1VF.0  BY  BLUE  G2  STAFF  SECTION. 

1010443 

AUG  1982 

UNCLASSIFIED 

(444) 

FROM: 

ASAC 

TO: 

CG,  62 ND  DIV/G2 

INFO: 

TYPE  REPORT: 

COMBAT  INTELLIGENCE  REPORT 

1. 

TIME: 

010350 

2. 

LOCATION: 

NA78329640 

3. 

DIR  MVMT: 

MSN 

4. 

RATE  MVMT: 

5  KPH 

5. 

UNIT  SIZE: 

COMPANY 

6. 

UNIT  TYPE: 

INF 

7. 

QTY  TANKS: 

NA 

8. 

QTY  APCS: 

NA 

9. 

ARTY  TUBES: 

NA 

10. 

UNK  VEHS: 

NA 

11. 

QTY  TROOPS: 

125 

SO 10449 

AUG  1982 

REO  ELEMS  627  TKR  CROSS  PHASE  LINE  VIC  NB60100100 

S0104S0 

AUG  1982 

RED  AIRMOBILE  ELEMS  623  MRR  LAND  VIC  NA67009900 

Figure  4-8.  Events  on  the  Controller’s  Message  Log. 
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The  sixth  entry,  printed  two  simulated  minutes  later,  shows  that 
the  Red  side  is  beginning  to  concentrate  its  airmobile  elements. 

The  seventh  entry  denotes  the  first  contact  between  the  opposing 
forces.  The  controller(s)  will  be  able  to  see  on  their  situation  map 
that  the  engagement  involves  the  Red  airlanded  units  and  the  Blue  ele¬ 
ments  of  the  2nd  Bde.  But  concomitant  with  the  event  printing,  the  IECR 
will  post  a  warning  to  the  control ler(s)  on  the  CRT  of  the  forthcoming 
release  event  representing  the  outcome  of  the  first  phase  of  this  engage¬ 
ment.  Before  the  next  event  associated  with  the  engagement  is  printed, 
the  controller(s)  will  have  acted  on  the  posted  warning  and  executed  the 
release  through  their  terminal. 

The  eighth  entry  records  the  receipt  of  the  coihbat  intelligence 
report  by  the  live  G2  players.  The  entry  is  an  exact  duplicate  of  the 
staff  input  printed  on  the  teletype  in  the  player's  room.  It  is  part 
of  the  basic  record  of  the  tactical  information  flow  to  the  players  by 
which  the  staff  performance  may  be  analyzed  after  the  end  of  the  exercise. 

The  ninth  and  tenth  entries  alert  the  controller(s)  of  further 
developments  in  the  unfolding  simulated  combat.  Nineteen  minuses  after 
the  start  of  the  play,  elements  of  the  Red  tank  regiment  cross  a  phase 
line  and  signal  to  the  control ler(s)  the  imminence  of  a  second  engage¬ 
ment  in  the  division  sector.  The  last  entry  in  the  twenty  minute  simu¬ 
lated  period  shows  that  the  Red  side  is  continuing  to  concentrate  its 
forces  in  the  area  of  the  first  point  of  contact. 

4. 2. 3. 3  Integrated  Simulation 

The  fundamental  characteristi cs  of  the  interactive  executive 
control  routine,  i.e.,  the  features  that  make  it  the  final  key  element 
of  the  proposed  implementation,  can  be  seen  by  comparing  the  "state  of 
the  battle"  information  held  by  one  side  (in  this  case  the  Blue  G2  Staff 
Section;  Figure  4-7)  with  the  real  world  state  seen  by  control ler(s)/ 
investigators  (Figure  4-8).  After  twenty  minutes  of  simulated  combat, 
the  G2  players,  because  of  the  and  reporting  delays,  are  as  yet  com¬ 
pletely  unaware  of  the  battle  events  unfolding  in  the  2nd  Brigade  area 
and  the  imminence  of  more  fighting  on  the  left  flank.  They  have  been 
informed  about  an  enemy  LRRP  discovered  in  the  3rd  Brigade  area,  but 
remain  largely  "in  the  dark"  about  the  rapidly  developing  situation. 

The  realistic  portrayal  of  the  combat  events  and  the  basic  control  of 
the  flow  of  the  tactical  information  to  the  staff  players  are  the  cen¬ 
tral  features  of  the  IECR  which  will  facilitate  the  running  of  the  sim¬ 
ulation  exercises. 

4.3.  BASIC  COMPONENTS  OF  THE  FIRST  IMPLEMENTATION 

This  subsection  now  presents  the  general  approach  SAI  proposes 
to  use  in  implementing  the  top-down  design.  The  key  elements  and  basic 
structure  described  in  the  preceding  subsection  can  be  implemented  most 
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effectively  by  using  a  coordinated  approach  in  which  the  required  soft¬ 
ware  and  structured  data  bases  are  all  developed  concurrently.  The 
following  specific  tasks  are  required: 

•  Concurrent  programming,  testing,  and  validation  of  the 
preprocessing  system,  the  interactive  executive  control 
routine,  and  the  magnetic  tape  SCENARIO  File  that  links 
the  routines  together. 

•  Development  of  the  computer-stored  tactical  message  for¬ 
mats  and  other  hard  wired  data. 

•  Structuring  of  the  Real  World  Data  Base  for  the  first 
scenario. 

•  Development  of  the  algorithms  for  initializing  the  Per¬ 
ceived  Data  Bases  and  for  the  degradation  of  tactical 
message  content  during  the  play. 

•  Development  of  the  random-access  Event  Table  File  and 
the  accompanying  event  loading  routine. 

•  Development  of  the  controller  release  event  data  entry 
procedures  and  display  screens. 

These  basic  components  of  the  integrated  simulation  are  discussed  fur¬ 
ther  here  in  the  framework  of  the  specific  computer  hardware  requirements. 

It  should  be  borne  in  mind  that  the  organization  of  the  material 
which  follows  does  not  imply  any  particular  order  of  importance  to  the 
various  components  nor  suggest  any  task  sequence  in  the  implementation 
effort.  The  required  elements  will  be  developed  and  fitted  together  all 
at  the  same  time  in  an  integrated  system  development  program.  An  im¬ 
plementation  plan  is  presented  in  paragraph  6.6. 

4.3.1  Concurrent  Development  of  all  Computer  Programs 

The  computer  software  will  be  the  principal  focus  of  the  proposed 
coordinated  approach.  SAI  will  embark  on  the  development  and  program¬ 
ming  of  all  computer  programs  simultaneously  by  employing  the  top-down 
programming  technique  of  creating  "skeletal"  computer  program  framew:.ks 
for  each  of  the  four  routines  cited  as  the  key  elements  of  the  system. 

A  skeletal  program  is  a  routine  containing  sufficient  computer  instruc¬ 
tions  to  demonstrate  the  overall  logical  structure  of  the  desired  func¬ 
tion  but  without  the  subroutines  necessary  for  the  more  subtle  logical 
details.  The  technique  has  been  successfully  applied  in  the  test  pro¬ 
gram  described  on  page  4-48  as  well  as  in  other  SAI  system  development 
efforts.  The  four  basic  programs  are  the  three  routines  comprising  the 
preprocessing  system  and  the  interactive  executive  control  routine  (IECR). 
The  skeletal  framework  that  will  emerge  in  the  early  stages  of  the  inte¬ 
grated  approach  will  be  a  system  capable  of  creating  by  successive  phases 
the  fundamental  SCENARIO  File  and  then  using  this  file  to  activate  the 
IECR. 
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The  system  flow  of  the  preprocessing  system  was  illustrated  in 
Figure  4-4. 

The  system  flow  of  the  IECR  is  shown  in  Figure  4-9.  The  opera¬ 
tion  of  this  program  is  conceived  to  consist  of  three  procedural  segments. 
In  the  first  segment,  the  input  magnetic  tape  SCENARIO  File  will  be  read 
in,  and  the  simulation  data  on  the  tape  will  be  reformatted  into  direct- 
access  disk  files,  as  shown  in  the  figure.  The  second  segment  will  be 
the  basic  event-store  simulator  with  its  asynchronous  interactive  con¬ 
trol.  The  operation  of  this  segment  was  described  in  paragraphs  4.2.2 
and  4.2.3.  The  third  segment  will  be  essentially  the  reverse  process  of 
the  first  segment.  In  response  to  controller  commands  or  to  certain 
simulated  time  clock  readings,  this  segment  will  take  the  existing  data 
in  the  direct-access  files  and  create  a  new,  modified  form  of  the  SCEN¬ 
ARIO  File. 

Beginning  with  these  skeletal  programs,  the  coordinated  approach 
can  best  be  described  as  the  process  of  putting  the  flesh  on  the  bones 
of  the  skeleton.  As  the  system  development  proceeds,  it  will  entail 
numerous  reformulations  of  the  program  structures,  many  separate  recom¬ 
pilations,  and  a  large  number  of  validation  test  runs.  The  preprocess¬ 
ing  programs  appear  to  present  only  straight-forward  programming  tasks 
except  for  the  basic  organization  of  their  end  product,  the  SCENARIO 
File.  Whenever  the  IECR  design  dictates  a  change  in  the  format  and/or 
content  of  its  input  SCENARIO  File,  the  preprocessing  system  will  have 
to  be  revamped  to  reflect  these  new  formulations. 

The  IECR,  unlike  the  preprocessors ,  combines  for  the  first  time 
a  number  of  sophisticated  techniques  in  a  logical  framework  tied  to  the 
computer  clock.  The  data  space  required  for  this  program  has  been  es¬ 
timated  to  be  316  kilobytes  (see  paragraph  4.1. 3.1).  Furthermore,  the 
instruction  space  is  estimated  to  be  1500  kilobytes.  These  estimates 
dictate  that  the  simulation  data  must  be  organized  into  direct  access 
disk  files  external  to  core  and  that  the  instructions  must  be  handled 
by  means  of  a  large  number  of  program  overlay  segments.  The  asynchronous 
trap  that  provides  for  the  simultaneous  battle  event  sequencing  and  in¬ 
jection  of  orders,  queries,  and  controller  release  executions  under  the 
timing  of  the  adjustable  simulated  clock  will  be  part  of  the  root  seg¬ 
ment  for  the  overlays. 

SAI  proposes  to  use  its  test  program  (see  page  4-48)  as  the 
starting  framework  for  the  IECR.  This  routine  has  already  successfully 
demonstrated  the  operation  of  the  asynchonous  interactive  control  coupled 
with  event  sequence  timing  based  on  the  computer  clock. 

The  development  of  the  programs  will  be  based  on  the  following 
specific  computer  hardware/software  requirements: 

•  PDP-11  computer  with  a  CPU  with  sufficient  memory  manage¬ 
ment  capabilities  to  provide  64  kilobytes  for  task  areas. 
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Figure  4-9.  System  Flow  Chart  of  the  Interactive  Executive  Control  Routine. 


fc* — 


•  Standard  peripherals,  including  high  speed  printer, 
magnetic  tape  unit(s),  card  reader,  and  disk  storage. 

This  system  will  require  its  own  disk  pack  (100  mega¬ 
bytes)  as  well  as  a  small  number  of  magnetic  tapes. 

•  Three  teletype  printers. 

•  One  CRT/keyboard  terminal,  possessing  "escape  sequence" 
controls  for  locking  and  unlocking  the  keyboard,  remote 
locating  and  repositioning  of  the  cursor,  and  clearing 
the  screen. 

•  The  RSX-11M  V03  Operating  System  with  its  standard 
utilities. 

•  The  FORTRAN-IV-PLUS  compilers  and  supporting  library. 

This  compiler  requires  a  floating  point  arithmetic 
hardware  unit  in  the  CPU. 

All  programs,  and  subroutines  except  the  I/O  control  and  asynchronous 
trap  routines  will  be  written  in  FORTRAN-IV-PLUS  language. 

4.3.2  Tactical  Message  Formats  and  Other  Hard  Wired  Data 

It  was  stated  previously  in  this  section  that  the  hard  wired 
data  used  in  the  simulation  would  be  stored  together  in  one  major  re¬ 
pository  in  the  computer.  The  repository  would  contain  the  repertoire 
of  tactical  message  formats,  the  dictionaries  of  permissible  words  or 
phrases  to  be  used  with  the  formats,  the  rate  of  advance  and  withdrawal 
tables,  etc.  and  would  require  approximately  100  kilobytes  of  data  space. 

In  the  light  of  the  basic  design  choices  made  for  the  implemen¬ 
tation  these  preliminary  determinations  did  not  take  into  account  the 
CRT  screen  formats  required  for  interactive  control  nor  the  program 
overlay  structure  to  be  used  with  the  IECR.  The  screen  formats,  which 
will  be  collected  together  within  the  major  repository,  may  increase 
the  data  space  requirement.  The  individual  tactical  message  formats, 
on  the  other  hand,  will  not  be  stored  together  but  instead  will  reside 
as  hard  wired  program  data  in  the  separate  overlay  segments. 

The  tactical  message  formats  to  be  used  in  the  simulation  are 
given  in  Design  Note  D. 

The  lists  or  dictionaries  of  permissible  words  or  phrases  to  be 
used  in  the  tactical  messages  will  be  composed  and  will  be  stored  as 
program  data  in  one  or  more  files  external  to  core. 

The  tables  of  combat  frontages,  troop  movement  rates,  rates  of 
advance  for  successful  attackers,  etc.  to  be  used  in  executing  battle 
events  will  also  be  composed  and  stored  in  external  files. 
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A  special  file  will  also  be  created  to  contain  the  various  screen 
formats  required  to  provide  the  controller/operator  with  instructions  for 
data  entry. 

These  data  will  be  fixed  or  invariant  and  as  internally  stored 
information  will  not  ordinarily  be  readily  visible  to  users  or  players 
of  the  simulated  war  game.  SAI  will  make  every  attempt  to  render  the 
black  box  magic  as  visible  as  possible  by  providing  printed  lists  and 
parameter  tables  as  part  of  the  basic  documentation  for  the  model. 

4.3.3  First  Scenario 


In  the  integrated  approach,  SAI  proposes  to  have  the  first  scen¬ 
ario  that  is  developed  to  exercise  the  model  serve  also  as  the  test  data 
vehicle  for  the  structuring  of  the  Real  World  Data  Base  and  the  composi¬ 
tion  of  the  list  of  exogenous  events.  Although  the  basic  design  will 
eventually  permit  the  synthesis  and  play  of  any  experiment/scenario 
combination  within  the  sizing  parameter  limitation,  the  computer  pro¬ 
grams  will  be  developed  around  this  test  scenario. 

SAI  proposed  that  this  first  scenario  reflect  a  European  setting 
similar  to  TRADOC's  "Standard  Scenario  for  Combat  Developments  (U)" 
(SCORES)  with  translation  sufficient  to  make  the  scenario  unclassified 
as  structured  and  played.  In  general  terms,  the  scenario  will  describe 
a  non-nuclear  attack  by  Warsaw  Pact  forces  ("RED")  against  the  US  V  Corps 
("BLUE")  in  the  Fulda  area  of  West  Germany.  Blue  covering  forces  are 
deployed  and  make  first  contact  with  leading  Red  elements  forward  of  the 
defensive  positions  of  the  simulated  Blue  division.  Initial  reports  and 
actions  are  those  found  in  the  sample  message  log  and  material  presented 
in  paragraph  4.2.3.  The  scenario  continues  to  completion  with  conven¬ 
tional  action  as  the  Blue  division  becomes  engaged  and  fights  its  battle. 

The  Real  World  Data  Base  for  the  model  will  be  structured  around 
the  composition  of  the  Blue  and  Red  forces  in  this  scenario.  This  means 
that  the  input  data  card  formats,  the  SCENARIO  File  records,  and  direct- 
access  files  of  the  IECR  will  tie  together  the  basic  force  tables  reflect¬ 
ing  the  Fulda  Gap-V  Corps  division-level  combat. 

The  list  of  exogenous  events  associated  with  the  scenario  will 
likewise  provide  the  basis  for  the  test  input  data  in  the  Phase  III 
Preprocessor. 

4.3.4  The  Perceived  Data  Base 


In  the  structuring  of  the  perceived  data  bases  for  the  computer, 
SAI  proposes  to  take  advantage  of  the  relationship  between  the  FRENSIT 
and  ENSIT  tables  in  the  tabular  arrays  and  the  force  tables  of  the  Real 
World  Data  Base.  Since  the  unit-by-unit  state  of  knowledge  data  in  the 
FRENSIT  and  ENSIT  tables  match  the  unit-by-unit  real  world  status  vari¬ 
ables,  the  tabular  arrays  and  the  force  tables  will  be  combined  into  a 
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single  direct-access  disk  file  keyed  by  a  unit  index.  The  structure  of 
this  file  is  illustrated  in  Figure  4-10. 

The  file  will  consist  of  300  records  of  approximately  300  bytes 
or  characters  each.  The  records  will  be  keyed  by  a  unit  index  varying 
between  1  and  300.  Unit  indices  1  to  150  will  cover  the  company-sized 
units  of  the  Blue  force;  the  indices  151  to  300  the  Red  force.  Each 
record  will  contain  approximately  200  bytes  of  real  world  status  infor¬ 
mation  plus  50  bytes  each  for  the  FRENSIT  data  and  ENSIT  data  associated 
with  the  unit.  In  the  sample  entries  shown  in  the  figure,  record  53 
will  contain  the  status,  location,  etc.  of  the  53rd  Blue  unit  as  well 
as  the  Blue  and  Red  perceptions  of  the  same  unit.  Similarly,  record  195 
will  contain  the  corresponding  groups  of  information  for  the  45th  Red 
unit  in  the  war  game.  The  tabular  array  of  data  heretofore  identified 
as  the  Blue  Perceived  Data  Base  in  now  more  fully  defined  as  the  FRENSIT 
information  over  the  first  150  records  and  the  ENSIT  data  in  the  last 
150  records.  It  is  shown  by  the  shaded  boxes.  The  Red  Perceived  Data 
Base  is  simply  the  remaining  unshaded  portion  on  the  right. 

It  can  be  seen  by  comparing  the  relative  sizes  of  the  real  world 
status  variables  and  the  FRENSIT  or  ENSIT  data  that  the  state  of  know¬ 
ledge  material  is  stored  by  the  use  of  special  coded  variables  and  is 
not  simply  a  biased  or  degraded  version  of  the  same  data  on  the  left. 

The  special  variables  will  consist  of  state-of-knowledge  indices  and 
reporting  time  parameters.  A  state-of-knowledge  (S0K)  index  will  be  a 
one-digit  integer  whose  value  will  be  a  quantitative  measure  of  the 
current  state  of  knowledge  about  an  item  of  friendly  or  enemy  force  in¬ 
formation.  The  reporting  time  parameters  will  be  simply  the  recorded 
date-time-groups  when  the  state-of-knowledge  indices  were  last  updated 
by  means  of  reporting  events  or  intelligence  processing  events.  The 
special  codes  will  provide  the  basis  for  a  compressed  data  storage  for¬ 
mat  as  well  as  for  the  algorithms  which  will  govern  the  biasing  or  de¬ 
grading  of  the  tactical  information  held  by  the  two  sides. 

The  algorithms  or  routines  controlling  the  SOKs  will  be  rooted 
to  a  set  of  internal  tables  relating  trie  :>0K  values  to  the  amount  or 
interpretation  of  the  error  by  which  the  perceived  facts  depart  from 
the  real  facts.  There  will  be  a  separate  table  for  each  identified  item 
of  friendly  or  enemy  force  information.  For  example,  there  will  be  a 
location  SOK  table  showing  the  range  of  probable  location  errors  ascribed 
to  each  of  the  ten  values  of  the  location  SOK  index.  By  reference  to 
these  tables,  the  routines  will  be  able  to  generate  or  change  aspects 
of  the  state  of  knowledge  held  by  the  Blue  or  Red  sides. 

A  special  routine  of  this  type  will  be  required  in  the  Phase  II 
Preprocessor  Program  because  the  basic  preprocessing  function  of  the 
program  is  the  initialization  of  the  SOK  indices  to  reflect  the  state 
of  knowledge  held  by  the  two  sides  at  the  beginning  of  the  simulated 
conflict.  One  feature  of  this  routine  will  be  the  use  of  standardized 
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or  "default"  values  for  the  various  categories  of  the  SOK  indices.  Thus, 
if  the  user/controller  wishes  to  set  up  an  exercise  reflecting  the  stand¬ 
ard  levels  of  knowledge  held  by  the  two  sides,  he  would  not  be  required 
to  feed  input  data  cards  into  the  program.  Alternatively,  if  for  the 
purposes  of  a  special  experiment  he  wished  to  slant  or  bias  the  states 
of  knowledge,  he  would  have  to  have  input  data  cards  prepared  which 
would  modify  the  standard  SOK  values  as  desired. 

The  logical  structure  of  all  SOK  routines  and  the  internal  SOK 
tables  will  end  up,  like  the  tactical  message  formats  and  battle  event 
tables,  as  hard  wired  elements  not  readily  visible  to  the  users  or  play¬ 
ers  of  the  game.  Here  again,  SAI  will  describe  these  otherwise  hidden 
subtleties  of  the  simulation  through  the  system  documentation. 

4.3.5  Event-Store  Simulator 


The  direct-access  Event  Table  File  shown  in  Figure  4-9  will  pro¬ 
vide  the  continuously  changing  schedule  of  events  on  which  the  battle 
simulation  will  be  based.  After  the  file  has  been  created  and  loaded  in 
the  first  procedural  segment  of  the  IECR,  the  program,  during  the  running 
segment,  will  access  and  update  the  file  in  two  separate  places  in  the 
basic  control  loop.  The  first  access  and  update  processes  will  occur 
preparatory  to  the  execution  of  the  occurrence  of  an  event.  The  second 
will  occur  whenever  a  newly-generated  event  must  be  scheduled  for  future 
occurrence  by  loading  it  into  the  file  and  then  rearranging  the  time 
sequence  among  all  the  event  records  to  preserve  the  correct  order  of 
occurrence. 

The  first  process  involves  accessing  and  updating  just  two  records 
in  the  file,  while  the  second  will  entail  numerous  random-access  reads. 

The  second  process  will  be  embodied  in  a  key  subroutine  called  the  event 
loading  routine.  The  development  of  this  subroutine  will  necessarily 
depart  from  the  conventional  logical  structure  of  event  loaders  and  will 
be  oriented  to  an  external  direct-access  file  instead  of  an  internally 
stored  event  list. 

1.3.6  Release  Events 


Controller  intervention  by  means  of  release  events  is  one  of  the 
key  features  of  the  model.  Although  some  types  of  release  events  are 
simply  a  convenient  means  for  handling  certain  kinds  of  staff  inputs  to 
populated  modules,  the  basic  reasoning  behind  most  release  events  is  as 
follows: 

•  Release  events  provide  a  means  for  the  investigator/ 
controller  to  influence  the  play  in  order  to  direct  the 
exercise  toward  the  research  objectives. 

•  Release  events  provide  a  means  for  a  human  being  to 
provide  certain  processes  such  as  terrain  analysis, 
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identification  of  routes  of  advance,  etc.  which  would 
otherwise  call  for  much  larger  computer  data  requirements. 

•  Release  events  provide  a  means  for  the  controller(s)  to 
invoke  military  judgement  in  certain  parts  of  the  simula¬ 
ted  battle. 

The  implementation  of  release  events  will  begin  by  identifying 
all  those  occurrences  among  the  Class  1  and  Class  5  events  where  con¬ 
troller  intervention  is  required.  Provision  must  then  be  made  that  the 
progenitors  of  these  events  trigger  the  pending  action  warning  to  the 
terminal  operator,  as  described  in  paragraph  4. 2. 2. 2.  Each  identified 
release  event  must  then  be  provided  with  its  own  formatted  screen  and 
edit/update  routine  through  which  the  terminal  operator  will  enter  the 
requisite  data  for  release. 

In  the  development  of  the  separate  edit/update  routines  and 
screens,  the  trade-off  between  the  human  engineering  requirements  for 
simple  keyboard  procedures  and  the  tight  instruction  space  limitations 
in  the  computer  will  be  addressed.  The  different  screen  formats  will 
be  collected  together  in  a  file  external  to  core,  but  the  individual 
routines  will  have  their  own  edit  tests  and  input  format  rules. 

4.4  FUTURE  EXTENSIONS 

This  subsection  addresses  the  question  of  how  amenable  the  pro¬ 
posed  system  will  be  to  specific  future  extensions.  The  preceding  dis¬ 
cussion  has  identified  three  basic  areas  where  the  proposed  implementa¬ 
tion  will  fall  short  of  the  full  scope  of  the  design  concept  and  whose 
future  incorporation  in  the  model  might  be  considered.  The  areas  are 
as  follows: 

•  ADP-assisted  staff  operations. 

•  Postprocessing  computer  programs  providing  (1)  statistical 
summary  analysis  of  the  action-handling  effectiveness  of 
live  and/or  simulated  staff  sections  and  (2)  event  trace 
analysis  identifying  the  sequence  of  events  which  led  to 
specific  staff  actions  during  the  exercise. 

•  The  play  of  any  configuration  of  populated  and  simulated 
modules,  including  that  of  up  to  5  live  Blue  Staff  Modules 
versus  the  live  Red  Command  Module. 

For  each  of  these  areas,  the  flexibility  of  the  current  design  structure 
is  examined  to  give  a  perspective  on  the  amount  of  effort  required  to 
extend  the  model.  The  discussions  follow  below.  In  the  examination  of 
these  areas,  or  while  considering  other  possible  directions  for  model 
extensions,  however,  the  reader  is  cautioned  that  in  computer  simula¬ 
tions  of  this  kind  there  always  exists  a  point  where  the  most  cost/ 
effective  approach  to  further  extensions  is  simply  a  new  basic  design 
concept. 
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4.4.1  ADP-Assisted  Staff  Operations 


The  extension  of  the  model  to  cover  the  simulation  of  ADP-assisted 
staff  operations  will  involve  computer  hardware  additions,  software  changes 
in  the  existing  computer  programs,  additional  programming,  and  the  deve¬ 
lopment  of  new  staff  action  procedures  (SOPs)  to  be  followed  by  the  live 
staff  modules.  The  following  specific  items  will  be  required: 

•  Two  ADP-assistance  terminals  which  duplicate,  or  match, 
the  terminals  to  be  used  in  the  field  with  respect  to 
the  keyboard  procedures,  the  display  characters,  and  the 
attendant  signal  lights  and  switches. 

•  The  definition  of  the  Class  6  events  and  the  specifica¬ 
tion  of  the  alternative  tactical  information  displays 
that  will  be  associated  with  the  events. 

•  Modification  of  the  IECR  so  that  the  software  accommodates 
asynchronous  interactive  data  entry  from  three  different 
CRT/keyboard  terminals. 

•  Modification  of  the  hard  wired  event  thread  sequences  so 
that  a  large  fraction  of  the  staff  input/output  now  goes 
through  the  player  terminals. 

•  Added  programming  for  the  computerized  decision-making 
aids,  including  the  employment  of  the  "scratch  pad"  data 
area  for  the  formulation  of  tactical  decision  alternatives. 

The  incorporation  of  these  items  will  not  alter  the  basic  structure  sig¬ 
nificantly,  but  will  clearly  change  the  way  the  live  staff  modules  will 
execute  their  staff  actions.  It  will  also  alleviate  some  of  the  work¬ 
load  implied  in  the  controller  functions,  since  the  control ler(s )  will 
now  be  required  to  perform  the  tactical  data  entry  function  for  only 
the  remaining  fraction  of  the  staff  outputs  not  handled  automatically 
by  the  divisional  tactical  data  system. 

It  is  recommended  that  when  this  extension  is  undertaken,  the 
new  version  of  the  battle  simulation  be  stored  on  a  separate  disk  pack 
independent  of  the  manual  staff  version  described  above.  This  expedient 
would  provide  the  means  for  alternative  exercises  of  simulated  combat, 
first,  under  manual  staff  procedures,  and  second,  under  ADP-assisted 
staff  operations.  Such  comparisions  may  serve  to  identify  further  some 
of  the  basic  features  and  problem  areas  of  a  field  ADP  system. 

4.4.2  Postprocessing  Computer  Programs 

The  extension  of  the  model  to  provide  statistical  summaries  of 
simulated  and  live  staff  performance  and  the  chains  of  events  whose 
simulated  occurrences  triggered  the  staff  actions  will  involve  little 
more  than  the  design  and  implementation  of  the  supplementary  computer 
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programs  performing  these  functions.  The  IECR  software  will  require  only 
minimal  modification  to  provide  a  suitable  output  processed  event  file 
which  will  serve  as  the  basis  for  the  postprocessing. 

The  postprocessing  functions  will  be  oriented  to  the  measures  of 
performance  described  in  paragraphs  2.4.4  and  2.4.6,  but  the  computer 
programs  will  stress  the  statistical  population  of  the  measures  over  the 
simulated  period  of  time  in  which  they  occurred.  Thus  the  postprocessor 
will  find  the  average  values  and  indicated  distributions  of  amounts  of 
time  taken  by  the  separate  staff  sections  to  complete  their  information 
processes.  The  measures  will  be  applied  to  both  simulated  and  live 
modules  in  order  to  provide,  for  comparison  purposes,  the  statistical 
norm  reflected  by  simulated  staff  sections  and  the  actual  performance 
by  populated  sections. 

The  postprocessor  will  also  help  identify  and  analyze  the  speci¬ 
fic  sequence  of  battle  events  that  led  up  to  periods  of  concentrated 
staff  activity  on  the  part  of  populated  staff  modules.  The  behavioral 
performance  measures  will  be  facilitated  by  the  ability  to  distinguish 
between  the  periods  when  the  staff  is  merely  pursuing  routine  staff 
actions  and  those  times  when  it  becomes  heavily  loaded  with  a  large 
number  of  required  actions  at  once. 

The  future  development  of  postprocessing  software  depends  pri¬ 
marily  on  the  identification  of  the  desired  performance  measures  to  be 
handled  in  the  new  computer  program.  After  a  certain  amount  of  exper¬ 
ience  has  been  attained  in  running  the  research  tool,  the  specification 
of  these  desired  measures  will  be  better  defined.  The  actual  program¬ 
ming  and  the  modifications  to  the  IECR  will  represent  relatively  modest 
extension  efforts. 

4.4.3  The  Play  of  More  Than  Two  Populated  Modules 

The  extension  of  the  model  so  that  it  permits  the  play  of  3  or 
more  populated  staff  modules  will  involve  the  reexamination  of  the  con¬ 
troller's  functions  and  the  basic  computer  assistance  he  (they)  are 
given.  The  increased  staff  output  message  traffic  will  probably  dictate 
a  controllers  team  of  more  than  two  people  as  well  as  additional  hard¬ 
ware  to  cover  the  added  volume  of  message  data  entry  traffic.  If  the 
basic  architecture  were  expended  to  cover  6  player  modules  (5  Blue  Staff 
Modules  and  one  Red  Command  Module),  the  overall  computer  hardware  re¬ 
quirements  for  a  manual  staff  version  would  be  as  follows: 

•  Two  or  more  controller's  CRT/keyboard  terminals. 

•  The  message  log  printer. 

•  Six  teletype  printers  for  the  player's  input  messages. 

This  requirement  would  have  to  be  augmented  by  the  six  player's  termi¬ 
nals  if  it  also  covered  the  ADP-assisted  staff  operations. 
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Modifications  to  the  IECR  software  would  be  required  in  order  to 
provide  the  correct  switching  and  routing  of  tactical  message  traffic 
among  the  various  devices.  Unfortunately,  the  expanded  software  would 
also  require  added  provision  for  the  coordination  of  separate  control 
functions  applied  at  different  CRT/keyboard  terminals.  Programmatic 
coordination  interlocks  of  this  kind  often  compound  the  problems  of 
software  development. 

Except  for  the  added  computer  hardware  and  software,  the  exten¬ 
sion  to  accommodate  any  configuration  number  shown  in  Table  4-1  would 
not  affect  the  underlying  simulation  structure  described  in  this  section. 

4.5  APPLICATIONS  OF  THE  TOP-DOWN  DESIGN 

Paragraph  2.1  stated  that  the  simulated  being  developed  should 
be  a  cost  effective  tool  for  behavioral  science  research  on  human  per¬ 
formance  in  the  division  command  group/staff,  for  combat  developments 
evaluation  of  tactics  and  doctrine,  and  for  training  command  groups/ 
staff  elements.  The  applicability  of  the  design  to  the  first  of  these, 
i.e.,  to  behavioral  science  research  is  discussed  at  length  in  Section 
5  as  it  applied  to  any  populated  module.  It  is  discussed  again  in 
Section  6  as  it  applies  to  the  G2  module.  The  remainder  of  this  sub¬ 
section  discusses  the  applicability  of  the  design  as  a  tool  for  combat 
developments,  evaluation  of  tactics,  and  doctrine,  and  as  a  training 
tool . 


4.5.1  Combat  Development  Applications 

A  simulation  of  the  nature  described  in  this  section  clearly 
has  application  in  the  general  area  of  evaluation  of  tactics  and  doc¬ 
trine.  It  is,  basically,  a  simulation  that  is  sensitive  in  terms  of 
combat  outcomes  to  the  decisions  made  by  a  commander  and  his  staff  at 
division  level.  These  combat  outcomes  are  especially  sensitive  to  de¬ 
cisions  that  affect: 

•  The  amount  of  contiat  (fire)  power  applied. 

•  The  conditions  under  which  it  is  applied  (terrain, 
posture,  etc.). 

•  The  time  and  duration  of  its  application. 

Because  it  is  an  event  store  simulation,  it  is  very  sensitive  to  the 
time  of  occurrence  of  battle  events  and  therefore  an  eminently  suitable 
vehicle  for  studying  the  dynamics  of  division  level  combat.  It  is  a 
very  detailed  representation  of  the  command  and  control  processes  at 
division  level  and  how  these  are  affected  by  the  performance  of  the 
subsystems  that  comprise  the  division  (maneuver,  fire  support,  intelli¬ 
gence,  EW,  communications,  logistics,  personnel,  etc.).  It  is  also 
sensitive  to  the  interactions  among  these  subsystems  that  are  established 
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through  decisions  affecting  organization  for  combat,  fire  support  manage¬ 
ment,  intelligence,  communications,  EW,  and  the  other  support  systems  as 
well  as  their  interactions  with  the  enemy.  It  is,  therefore,  an  excellent 
vehicle  for  studying  the  command  and  control  of  division  assets,  but  it 
is  dependent  on  inputs  to  the  simulation  which  specify  the  performance 
parameters  of  the  subsystems  being  managed.  These  parameters  can  be 
varied  to  alter  initial  performance  at  the  beginning  of  the  simulation 
run  and  will  be  altered  as  the  battle  progresses  to  reflect  changes  that 
may  occur,  e.g.,  attrition.  The  simulation  is  not  useful  for  developing 
the  performance  parameters  of  the  building  blocks  of  the  model  (units 
and  subsystems  that  comprise  the  force).  It  can,  however,  be  used  to 
examine  how  the  decision  making  process  is  altered  as  a  result  of  changes 
in  performance  parameters  and  how  the  changes  affect  the  outcomes  of 
combat,  e.g.,  changes  in  the  performance  of  the  information  system  that 
feeds  the  decision  making  elements  of  the  staff. 

Figure  4-11  is  a  representation  of  a  dynamic  combat  model  of  the 
kind  described  in  the  preceding  paragraph.  The  entire  friendly  and 
enemy  forces  are  defined  in  terms  of  their  personnel ,  materiel,  and  opera¬ 
tional  concepts  as  these  determine  their  organization  and  procedures. 
Together  these  determine  the  performance  parameters  of  the  subsystems 
that  comprise  the  force.  Unless  these  simulation  inputs  are  modified 
by  extraneous  changes  (by  players)  the  interaction  between  the  forces 
is  a  stationary  process,  i.e.,  force  capabilities  are  modified  only  by 
interaction  with  the  enemy  and  the  outcome  is  "limiting"  in  the  sense 
that  no  effort  has  been  made  to  optimize  the  outcome  by  altering  opera¬ 
tional  concepts  (tactics  and  doctrine).  If,  however,  the  loop  is  opened 
periodically  so  that  the  results  of  combat  are  fed  back  to  players  who 
have  an  opportunity  to  alter  the  operational  concepts,  and  compare  them 
with  old  or  standard  concepts  or  to  compare,  e.g.,  Soviet  and  NATO 
organization,  tactics,  doctrine,  and  capabilities  and  procedures. 

For  this  reason  the  connection  between  proposed  doctrine  and  changes  to 
operational  concept  is  a  double  headed  arrow.  Just  as  important  in 
such  an  investigation  as  the  comabt  outcomes  in  terms  of  area  exhanged, 
resources  consumed,  and  time  expended  in  terms  of  probable  set  of  changes 
in  operational  concept  developed  by  an  alert  enemy  as  he  learns  to  cope 
with  new  and  unexpected  threat  behavior.  The  simulation  described  pre- 
vously  in  this  section  is  precisely  of  this  kind. 

Among  the  kinds  of  tactical  and  doctrinal  questions  that  can  be 
examined  effectively  by  this  division  level  battle  simulation  are: 

•  Maneuver  Force 

-Task  organization 
-Missions 
-Echelonment 
-Dispositions 

-TOEs  (must  first  be  transformed  into  performance  para¬ 
meters  acceptable  by  the  model,  e.g.,  firepower,  move¬ 
ment  rates,  response  time,  etc.) 
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•  Fire  Support  Units 

-Allocation  of  artillery  support  (DS/GS) 

-Allocation  of  Army  assets 
-Allocation  of  close  air  support  (CAS) 

-Targeting  priorities 

-TOEs  (as  reflected  in  performance  parameters) 

-Nuclear  planning  and  execution 

t  Other  Support  Systems 

-Allocation  of  Intelligence  assets 

-Intelligence  reporting  procedures  (as  reflected  in  per¬ 
formance  parameters) 

-Communication  policy  (as  reflected  in  performance  para¬ 
meters  to  include  effects  of  enemy  jamming) 

-EW  policy  (to  include  effects  on  friendly  communications) 
-Allocation  of  Army  air  assets  to  transportation  tasks. 

Since  such  a  simulation  is  designed  to  run  for  periods  not  normally  ex¬ 
ceeding  12  hours  of  combat,  it  will  not  be  sensitive  to  most  personnel 
and  logistic  decisions  except  as  these  influence  the  status  of  forces 
at  the  opening  of  hostilities.  Most  such  decisions,  '  xcept  for  limited 
redistribution  of  assets  by  Army  air,  will  not  affect  the  battle  out¬ 
come  within  such  a  short  time  frame. 

4.5.2  Training  Applications 

As  has  already  been  discussed  in  paragraph  2.4.4,  the  applica¬ 
tion  of  such  a  simulation  to  the  task  of  training  command  group/staffs 
involves  features  of  the  model  already  discussed  and  provided  for  the 
first  two  applications.  A  simulation  is  clearly  applicable  primarily 
to  those  steps  in  the  education  process  that  involve  application  of 
information  and  principles  a  student  has  already  learned,  to  evaluation 
of  his  performance  after  application,  and  to  reinforcement  of  such 
learning.  As  such  there  are  two  distinct  levels  of  training  to  which 
it  would  be  applicable. 

•  Teaching  staff  procedures  and  the  mechanics  of  staff 
processing. 

•  Teaching  the  doctrinal  or  policy  basis  for  decision  making 
These  are  described  in  the  following  subsections. 

4. 5.2.1  Procedural  Instruction 


The  simulation  is  obviously  applicable  for  the  purpose  of  teach¬ 
ing  a  small  group  of  staff  personnel  the  mechanics  of  routine  staff 
procedures.  It  can  be  used  to  provide  the  triggers  for  generating  the 
information  processing  required  to  produce  specified  outputs,  whether 


these  be  provided  by  sources  external  to  the  staff  module  or  generated 
by  the  clock  and  a  Standing  Operating  Procedure.  The  necessary  informa¬ 
tion  inputs  can  be  provided  either  on  an  automatic  distribution  basis 
or  accessed  as  required  by  the  students.  This  can  cover  as  much  as  or 
as  little  of  the  available  repertoire  of  message  types  (decision  variables) 
as  desired. 

Evaluation  of  the  performance  of  individuals  within  the  staff 
module  or  of  the  entire  module  involves  a  combination  of  measurements 
made  of  individual  staff  operations  procedures  and  measurements  made  in 
the  information  stream  at  the  module  boundaries.  Such  measurements  can 
be  made  of  the  time,  effort  (in  terms  of  man-hours  or  man-minutes), 
completeness,  and  accuracy  of  the  information  outputs,  files,  or  displays. 
Paragraph  5.2.1  contains  a  detailed  discussion  of  the  measures  appropriate 
and  available  at  the  boundaries  of  the  module;  paragraph  5.2.2  outlines 
the  techniques  for  internal  measurement  of  these  quantities. 

4. 5. 2. 2  Training  in  Doctrine  or  Policy 

The  simulation  is  also  an  excellent  vehicle  for  this  higher 
level  of  training  in  that  it  puts  student  decision  makers  into  a  realistic 
combat  environment  and  requires  that  they  make  the  same  kinds  of  deci¬ 
sions  that  must  be  made  in  actual  combat.  The  evaluation  of  student 
performance  and  reinforcement  of  preferred  tactis  and  doctrine  are  pro¬ 
vided  through  realistic  combat  outcomes  which  indicate  to  the  student 
the  validity  of  his  decisions  by  showing  him  their  effect  on  mission 
performance.  Such  a  tool  will  provide  far  more  credible  reinforcement 
than  does  the  "school  solution"  in  a  classroom  situation.  The  appli¬ 
cable  combat  outcome  parameters  are  also  discussed  in  paragraph  5.2.1. 

The  strong  parallel  between  evaluation  of  new  tactics  and  doctrine  and 
the  evaluation  of  student  decision  makers  should  be  noted. 
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Section  5 


INSTRUMENTATION  OF  LIVE  MODULES 
5.1  COST  OF  REALISM 

In  designing  the  live  staff  module  there  is  an  important  trade¬ 
off  that  must  be  considered.  This  tradeoff  is  between  the  realism  of 
the  decision-making  environment  and  the  size  (hence,  complexity  and  cost) 
of  running  the  simulation.  The  facet  of  realism  being  addressed  here  is 
the  third  principle  enunciated  by  Sackman*  i.e.,  the  Conversational 
Principle.  For  this  application  his  statement  is  paraphased  as  follows: 

•  Conversational  Principle:  Human  performance  in  man/ 

(simulation)  dialog  will  vary  with  the  similarity  of  the 
responding  (simulation)  to  tne  real  time  exchange  charac¬ 
teristics  of  human  conversation  ...  As  (simulation)  re¬ 
sponse  time  and  message  pattern  deviate  increasingly  from 
real  time  parallelism  ...  so  will  user  performance  (vary). 

The  difference  in  conversational  realism  occasioned  by  the  size  of  the 
live  staff  module  can  be  appreciated  by  comparing  two  extremes.  At  one 
extreme  are  the  staff  section  workshops  conducted  at  Ft.  Hood  in  1974 
under  the  auspices  of  HQ  MASSTER.  For  these  workshops  the  normal  day¬ 
time  "shift"  of  a  staff  section  was  assembled  together  with  its  TOE 
equipment  down  to  the  last  telephone  and  radio  and  disposed  in  replicas 
of  their  vans  and  tents  in  the  field.  The  simulation  of  outside  world, 
to  include  other  staff  sections,  was  provided  by  a  group  of  controllers. 
Everything  was  done  to  try  to  place  the  staff  section  in  an  environment 
that  allowed  internal  data  processing  to  proceed  just  as  it  does  when 
the  unit  is  in  the  field  and  which  would  make  the  outside  world  (as 
painted  by  the  message  traffic)  appear  as  it  would  in  combat.  This  was 
truly  an  iconic  model  in  that  it  certainly  looked  like  the  real  thing. 

The  conversational  principle  was  adhered  to  very  strictly.  However, 
the  cost  of  conducting  extensive  experimentation  in  this  manner  is 
prohibitive.  It  required  the  services  of  more  than  75  military  person¬ 
nel  to  man  one  staff  section  and  to  provide  controllers  and  data 
collectors. 

At  the  other  extreme  is  SIMTOS  which  required  only  a  single 
player  within  the  staff  section  and  virtually  no  human  control.  In  a 
sense,  this  is  not  a  fair  comparison,  for  the  workshops  were  simulations 
that  permitted  a  staff  to  operate  in  a  manual  mode  while  SIMTOS  was  a 
simulation  designed  to  permit  a  decision  maker  to  operate  aided  only 
by  a  computer  and  I/O  devices  which  could  present  to  him  the  aggregated, 
evaluated,  and  synthesized  information  that  would  have  been  presented 
to  him  by  the  other  members  of  his  staff.  Nevertheless,  if  one  were  to 
attempt  the  SIMTOS  approach  to  building  a  simulation  for  study  of  a 
staff  operating  in  the  manual  mode  the  conversational  principle  would 
certainly  be  violated.  Yet,  the  operating  costs  would  be  minimal. 

*H.  Sackman.  Computers,  Systems  Science  and  Evolving  Society.  New  York, 
John  Wiley,  1967 
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The  nature  of  the  trade-off  can  be  appreciated  by  referring  to 
Figure  2-5.  This  figure  illustrates  the  nature  of  the  data  processes 
for  both  manual  and  ADP-assisted  operations.  The  interface  between 
staff  and  communication  processes,  i.e.,  the  simulation,  occurs  at  the 
bottom  of  the  figure  in  the  purely  manual  mode.  Much  of  the  time  and 
effort  of  a  manual  staff  module  is  consumed  in  the  lower  staff  processes, 
e.g.,  receiving,  transmitting,  tagging,  sorting,  updating,  etc.  Thus, 
if  the  interface  between  the  simulation  and  the  manual  processes  is 
moved  up  to  the  higher  process  levels,  much  manpower  can  be  saved,  but 
the  farther  one  moves  the  interface  in  this  direction,  the  less  realis¬ 
tic  the  "manual"  operation  becomes. 

On  the  other  hand,  if  the  live  staff  module  is  operating  in 
an  ADP-assisted  mode  one  faces  a  different  design  problem.  The  simulation 
must  now  perform  the  ADP  processing  that  would  be  performed  by  a  TOS, 
thus,  the  interface  between  the  live  players  and  the  simulation  has 
moved  to  the  man/machine  interface  illustrated  in  the  figure.  Clearly, 
such  an  ADP-assisted  staff  can  be  substantially  smaller  than  a  purely 
manual  staff  if  the  simulation  is  doing  much  of  the  lower  level  data 
prpcessing.  The  problem  now  is  not  one  of  manpower  costs  for  the  oper¬ 
ation,  but  one  of  accommodating  a  range  of  different  man-machine  in¬ 
terfaces.  Presumably,  one  would  want  to  use  such  a  simulation  to  in¬ 
vestigate  the  effectiveness  of  alternative  software  and  hardware  com¬ 
binations.  This  has  already  been  alluded  to  in  Section  3.4.6.  Even 
if  the  rest  of  the  simulation  is  essentially  hard-wired,  the  software 
development  costs  for  simulating  a  wide  range  of  ADP  assistance  would 
be  substantial. 

The  following  approach  will  be  used  in  addressing  these  prob¬ 
lems.  Every  effort  will  be  made  to  design  the  live  staff  module  so 
that  it  can  operate  as  realistically  as  possible  in  both  the  manual 
and  ADP-assisted  modes.  The  impact  on  simulation  structure  is  that 
provision  must  be  made  for  a  "perceived  data  base"  for  both  Blue  and 
Red  in  addition  to  the  real  data  base  which  will  represent  ground 
truth.  Such  a  perceived  data  base  is  required  for  any  ADP-assisted 
operation  in  which  the  players  are  permitted  to  query  a  data  base  in 
order  to  retrieve  sorted,  updated,  and  aggregated  data.  This  feature 
will  also  be  useful  in  the  manual  mode  if  the  player  wants  to  query 
subordinate  units,  for  example,  for  such  information. 

In  designing  the  purely  manual  module,  consideration  will  be 
given  to  reducing  the  number  of  the  required  players  by  including 
some  lower  level  processing  within  the  simulation.  For  example,  much 
of  the  message  traffic  which  would  ordinarily  require  players  to  sit 
at  radio  and  telephone  instruments  in  order  to  transcribe  or  transmit 
hardcopy  can  be  provided  to  or  accepted  from  the  players  in  hardcopy 
form.  This  does  not  necessarily  mean  that  all  traffic  with  the  out¬ 
side  world  would  be  in  hardcopy,  because  that  would  seriously  violate 
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the  conversational  principle.  Some  filing  and  recording  activities 
may  also  be  performed  by  the  simulation  in  order  to  reduce  manpower 
requirements. 


In  designing  the  ADP-assisted  provisions,  every  effort  will 
be  made  to  make  the  basic  simulation  structure  as  flexible  as  possible, 
so  that  many  different  interfaces  can  be  supported.  The  initial  design 
will  provide  for  a  minimal  number  of  different  kinds  of  man-machine  in¬ 
terfaces  with  provisions,  however,  for  proliferation  later  as  new  prob¬ 
lems  and  funds  to  support  them  may  arise. 

5.2  PERFORMANCE  MEASUREMENT 

Some  of  the  pertinent  considerations  affecting  live  staff  per¬ 
formance  measurement  have  already  been  addressed  in  paragraph  2.4.4. 
There  it  was  pointed  out  that  measurements  within  the  information  net¬ 
work  are  limited  to  measurements  of  time  and  effort  associated  with 
the  preparation  of  specified  staff  outputs  and  measurements  of  infor¬ 
mation  content  of  such  outputs  such  as  completeness,  accuracy  and  va¬ 
lidity  for  a  very  limited  portion.  It  was  further  pointed  out  that 
complete  measurements  of  the  quality  of  information  content  cannot  be 
made  entirely  within  the  information  system  but  must  be  inferred  from 
the  outcomes  of  the  combat  simulation.  Points  between  which  certain 
classes  of  measurement  can  be  made  were  also  defined. 

In  view  of  the  modular  nature  of  this  simulation  and  the  basic 
design  concept  which  provides  that  every  information  transfer  across 
the  boundaries  of  a  staff  module  must  be  made  explicity,  the  measure¬ 
ment  of  staff  performance  can  be  divided  into  measurements  made  at  the 
boundaries  of  live  staff  modules  and  measurements  within  staff  modules. 
Each  of  these  is  discussed  in  the  following  subparagraphs. 

5.2.1  Measurement  Outside  the  Staff  Module 

The  top-down  design  outlined  in  Section  4  provides  for  the 
following  kinds  of  measurements  at  the  module  boundaries: 

•  Logging  the  time  of  entry  into  the  simulation  of  every 
staff  output.  This  includes  out  puts  which  are  entered 
into  the  computer  and  those  outputs  which  are  simply 
recorded  and  filed. 

•  Logging-  the  time  of  delivery  of  every  staff  input  pro¬ 
vided  to  live  players  whether  those  are  generated  by 
the  computer  or  delivered  by  the  controller  from  the 
file  of  previously  prepared  written  entries. 


Recording  the  content  of  every  staff  input  and  output 
whether  processed  by  the  computer  or  hand  processed  by 
Control . 


From  these  recorded  data  the  following  kinds  of  performance  measure¬ 
ments  can  readily  be  extracted: 

•  Time  delays  between  selected  inputs  and  outputs 

•  Time  delays  between  selected  triggers  and  outputs 

•  Completeness  of  selected  staff  outputs  with  respect  to 
inputs  provided 

•  Accuracy  of  selected  staff  outputs  with  respect  inputs 
provided 

•  Numbers  of  selected  outputs  generated 

•  Numbers  of  selected  inputs  provided 

•  Numbers  of  queries  generated  for  selected  classes  of 

information. 

Measurement  of  the  quality  of  the  content  of  staff  module  de¬ 
cisions,  as  evidenced  by  the  outputs,  must  be  made  in  terms  of  their 
effects  on  the  battle  outcome.  The  discussion  at  paragraph  2.4.6 
indicated  the  effectiveness  measures  that  can  be  used  to  measure  the 
relative  mission  accomplishment  of  alternative  solutions  to  battle¬ 
field  management.  These  are: 

•  Changes  in  geographic  area  controlled  by  each  side 

•  Changes  in  the  resources  consumed  and  available 

•  Time  intervals  required  to  effect  above  changes 

The  design  delineated  in  Section  4  provides  these  output  measures  as 
fol lows : 

•  Changes  in  geographic  area  are  available  as  unit  loca¬ 
tions  both  in  the  Real  Data  Base  and  on  the  Controllers 
SITMAP 

•  Changes  in  resources  are  available  as  characteristics 
of  the  units  whose  status  is  maintained  in  the  Real 
Data  Base 
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•  Time  to  effect  these  changes  is  inherent  in  an  event 
store  simulation  which  records  the  time  every  change 
in  unit  characteristics  (to  include  location)  is  ef¬ 
fective. 

5.2.2  Measurements  Inside  the  Staff  Modules 


Dynamic  processes  such  as  the  data  processing  performed  with¬ 
in  a  live  staff  module  can  be  studied  in  either  or  a  combination  of 
two  modes:  by  time  of  occurrence  of  observable  events,  or  by  observ¬ 
ing  behavior  at  time  increments.  The  latter  technique  is  particularly 
applicable  to  the  study  of  human  behavior  when  the  subject  is  engaged 
in  repetitive,  mechanical  tasks  (time  and  motion  studies)  for  which 
motion  pictures  provide  an  excellent  recording  and  measurement  medium. 
However,  this  technique  has  severe  limitations  when  applied  to  the 
study  of  information  processing.  It  fails  to  capture  significant 
data,  e.g.,  the  content  of  the  information  stream,  and  the  very  volume 
of  data  collected  poses  a  formidable  data  reduction  problem. 

An  alternative,  event-oriented  approach  to  the  study  of  infor¬ 
mation  processing  has  been  used  with  some  success  in  defining  such 
processes.!  This  involved  breaking  staff  processes  down  into  a  series 
of  elementary  operations  such  as  those  listed  at  Table  5-1.  The  in¬ 
itiation  and  completion  of  each  such  elementary  operation  is  an  ob¬ 
servable  event  as  is  entry  of  an  action  into  a  players'  queue  or  re¬ 
moval  from  queue.  Recording  the  sequence  of  such  operations,  the 
time  required  for  each,  the  time  spent  in  queue,  the  player  who  per¬ 
forms  each  and  the  station  at  which  an  operation  is  performed  plus  a 
copy  of  the  information  transferred,  recorded,  plotted,  etc.,  provides 
one  useful  means  for  describing  the  information  process.  The  results 
of  such  a  study  can  be  plotted  in  flow  chart  form  as  at  Figure  5-1. 

Such  data  are  particularly  useful  for  the  simulation  of  information 
processes.  There  remain  problems  of  designing  instrumentation  which 
does  not  interfere  or  interact  with  the  information  processing. 

The  discussion  at  paragraph  2.4.4  has  already  indicated  that 
the  measurement  of  data  processing  is  limited  to: 

•  Effort  and  delay  times  for  individual  processes  (from 
which  the  process  sequence  can  also  be  deduced). 

•  Completeness  of  data  outputs  which  are  a  priori  combi¬ 
nations  of  input  data. 

•  Accuracy  of  data  outputs  which  are  a  priori  combinations 
of  input  data. 


^Tiede,  R.  V.,  et  al ,  "The  Integrated  Battlefield  Control  System  (IBCS) 
Third  Refinement  Final  Report,"  Science  Applications,  Inc.,  31  March 
1975. 
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Table  5-1.  Elementary  Operations 


THROUGHPUT  OPERATIONS 

Receive  Radio  (Rev  Rad):  All  action  steps  required  to  produce  a 
written  copy  of  an  incoming  message  via  radio  to  include  required 
radio  operating  procedures. 

Receive  Telephone  (Rev  TP):  All  action  steps  required  to  produce 
a  written  copy  of  an  incoming  message  via  telephone  to  include 
required  telephone  operating  procedures. 

Receive  RATT  (Rev  RATT):  All  action  steps  required  to  produce  a 
written  copy  of  an  incoming  message  via  RATT  to  include  required 
RATT  operating  procedures. 

Receive  Aurally  (Rev  Aur):  Reduction  of  an  oral  transmission  to  a 
written  form. 

Transmit  Orally  (Xmit  Oral):  All  action  steps  required  to  convey  a 
written  message  by  unaided,  human  voice  to  a  predesignated  addressee(s) 

Plot  on  Map  (Plot) :  Post  or  update  symbols  on  map. 

Enter  in  Journal  (Enter):  Physical  process  of  recording  in  journal, 
workbook  or  list. 

Retrieve  (Rtrv):  (Must  be  associated  with  a  specific  file  or  display.) 

•  ♦  m  .  •  • 

Locating  and  extracting  from  a  particular  file  or  display. 

Compose:  Prepare  a  draft  of  a  product  or  portion  of  a  product. 

Hake  Overlay  (Overlay):  Physical  preparation  of  map  overlay. 

Post  Display  (Post):  Enter  or  update  data  on  visual  display. 

BRANCHING  OPERATIONS 

Determine  Internal  Routing  (DIR):  Read  for  content  and  select 
addresses/station  routing  within  element  for  further  processing  of 
that  product. 


Table  5-1.  Elementary  Operations  (Continued). 


Determine  External  Routing  (PER):  Read  for  contort  and  select 
external  addressee(s) . 

Reproduce,  Manual  (Repro,  Mr. n ) :  Production  of  an  exact  handwritten 
ccpy  (may  be  multiple  copies  using  carbon  paper). 

Reproduce,  Machine  (Repro,  Mach):  Production  of  an  exact  copy  (or 
copies)  utilizing  copy  machine. 

Tj/ge:  Production  of  an  exact  copy  using  a  typewriter.  (May  be 
multiple  copies  using  carbon  paper.) 

COLLECT ICM  OPERATIONS 

Consolidate  and  Approve  (C&A):  Accept,  integrate,  edit  portions  of 
a  product  produced  by  more  than  ore  source  and  release  final  product 
for  distribution  (normally  to  external  addressees).  The  same  opera¬ 
tion  is  used  for  approval  only  in  which  case  there  is  a  single  input. 

TERMINATING  OPERATIONS 

File:  (Must  be  associated  with  a  specific  station.)  To  place  a 
product  or  extract  therefrom  in  a  designated,  closed  (nondi splay) 
storage  place  or  to  update  a  permanert  (nondisplay)  record 

Terminate  (Term):  This  ccpy  goes  no  further  and  is  placed  in  File 
13  or  convenience  file. 

Transmit  Radio  (Xmlt  Rad):  All  action  steps  required  to  convey  a 
written  message  via  radio  to  a  predesignated  addressee  to  include 
required  radio  operating  procedures. 

Transmit  Telephone  (Xmit  TP):  All  action  steps  required  to  convey  a 
written  message  via  telephone  to  a  preuosignated  addressee  to  include 
required  telephone  operating  procedures. 

Transmit  RATT  (Xmlt  RATT):  All  action  steps  required  to  convey  a 
written  message  via  RATT  to  a  prcrics’gnated  addressee  to  include 
required  RAiT  operating  procedures. 

Transmit  Courier  (N'nil  Cour):  Picking  up  an  action  from  an  outbox, 
courier,  other  staff  member,  or  self  and  delivoirnn  it  to  a  predeter¬ 
mined  aflilrQs$?c/st*tion  or  tr>s  inbox. 
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•Ti 


The  completeness  and  accuracy  of  all  other  outputs  and  the  validity 
of  all  outputs  cannot  be  measured  directly  and  must  be  inferred  from 
the  battle  outcomes. 

One  technique  that  has  been  used  to  make  time  and  effort  mea¬ 
surements  is  the  installation  of  time  clocks  at  every  operator/station. 
The  time  clock  stamp  also  contains  a  unique  identifier  for  every 
operator/station.  The  requirement  to  insert  every  message  into  the 
time  clock  for  every  elementary  operation  does  introduce  some  ex¬ 
traneous  "noise"  into  the  operation,  but  the  alternative  problem  of 
data  reduction  that  accompany  collecting  such  data  by  means  of  movie 
cameras  is  indeed  formidable.  Clearly  the  time  clock  technique  would 
be  useful  only  for  tracking  the  flow  of  hardcopy.  In  the  same  way, 
completeness  and  accuracy  of  files  and  displays  can  also  be  measured 
by  comparison  with  data  inputs,  but  this  again  is  limited  to  hardcopy. 
For  special  imited  applications  it  would  be  possible  to  capture  some 
of  these  data  by  some  combination  of  cameras  and  sound  recording. 

For  an  ADP-assisted  staff,  the  measurement  problem  is  substantially 
easier  since  the  I/O  devices  can  be  used  to  collect  much  of  the  needed 
data. 


There  is  at  least  one  other  approach  to  the  study  of  informa¬ 
tion  processing  which  concentrates  on  the  process  rather  than  on  the 
events.  This  involves  some  combination  of  individual  interview,  group 
discussions,  questionnaires,  etc.,  to  collect  data  directly  from  the 
subjects.  The  pitfalls  inherent  in  such  subjective  and  introspective 
techniques  are  only  too  well  known  to  behavioral  scientists  if  data 
collected  in  this  marier  are  not  confirmed  by  experimental  evidence. 

In  the  case  of  the  study  cited  above,  data  were  also  collected  by  such 
subjective  means.  Some  general  observations  as  to  the  validity  of  the 
data  collected  by  these  means  are  pertinent. 

t  The  sequence  of  operations  defined  in  this  manner 

tended  to  be  very  complete,  highly  stylized,  and  "by 
the  book." 

•  dob  assignments  were  on  a  basis  of  primary  skills  and 
an  unofficial  "pecking  order".  For  example,  principal 
staff  officers  did  not  answer  telephones  or  radios, or 
hand-deliver  messages. 

•  dob  assignments  were  made  without  regard  to  individual 
loadings  on  either  personnel  or  equipment.  Standing 
Operations  Procedures  (SOPs)  indicated,  for  example, 
that  all_  outgoing  traffic  would  be  validated  by  the 
senior  staff  officer  present. 

•  The  sequence  of  individual  operations  tended  to  be 
linear  with  minimal  parallel  processing. 
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•  In  short,  SOPs  developed  in  this  manner  tended  to  be 
idealized  representations  that  could  be  followed  only 
under  "no-load"  conditions. 

Experimental  data  collected  by  more  objective  mans  showed  marked  changes 
in  these  procedures  when  staffs  were  subjected  to  live  loads. 

•  A  live  load  tended  to  streamline  processing  procedures. 
Unnecessary  frills  were  eliminated  and  there  was  evi¬ 
dence  of  much  greater  parallel  processing. 

•  Job  assignment  became  much  more  "democratic".  Tasks 
tended  to  be  performed  by  whatever  qulaified  person 

was  available.  Officers  answered  telephones  and  radios. 

e  The  sequence  of  elementary  operations  was  altered  to 
route  traffic  around  large  bottlenecks  and  long  queues 
or  the  sequence  was  inverted  to  keep  the  action  moving. 

•  More  traffic  was  handled  orally. 

•  Under  severe  loading,  processing  became  so  curtailed 
that  significant  information  was,  indeed,  ignored  and 
some  queues,  e.g.,  that  of  the  file  clerk,  became  ever- 
increasing. 

The  above  experience  does  not  mean  that  subjective  methods  have  no 
value.  They  can  be  of  significant  help  in  making  preliminary  process 
definitions,  but  they  must  be  corroborated  or  modified  as  the  result 
of  objective  experimentation. 

In  summary,  our  consideration  of  possible  alternatives  to  live 
staff  instrumentation  leads  us  to  the  following  conclusions: 

•  The  collection  of  data  regarding  player  performance  in 
the  manned  staff  modules  can  be  accomplished  either  on 
a  time  increment  basis  or  through  event-oriented  tech¬ 
niques.  At  this  time,  some  combination  of  both  alterna¬ 
tives  seems  desirable. 

•  Subjective  techniques  (interview,  questionnaires,  group 
discussions,  etc.)  may  be  useful  for  formulating  initial 
concepts  as  to  staff  behavior,  but  must  be  verified  or 
modified  through  objective  experiment. 

5.3  CONTROL  PARAMETERS 

To  be  useful  for  human  factors  research  on  the  behavior  of 
decision  makers  within  populated  staff  modules,  the  simulation  must 


provide  control  parameters  to  the  experimenter  that  can  adjust  the 
quality  and  quantity  of  information  used  by  the  decision  maker  (player). 
A  number  of  categories  of  such  control  can  be  identified.  These  include 

•  Control  of  the  amount  and  kind  of  information  provided 
to  populated  staff  modules  for  a  specified  scenario. 

•  Control  of  the  availability  of  "source  identity"  to  a 
populated  G2  module. 

•  Control  the  time  constraints  imposed  on  a  populated 
staff  module  for  its  decision  making. 

•  Control  the  quality  of  the  information  provided  to  a 
populated  staff 'module. 

The  top-down  design  described  in  Section  4  provides  one  or 
more  basic  control  parameters  for  each  of  these  categories.  These  are 
described  in  the  following  paragraphs. 


5.3.1  Amount  and  Kind  of  Information 

The  basic  control  parameters  for  this  category  are: 

1.  Change  the  distribution  of  message  types  provided 
automatically  to  a  populated  staff  module  (Automatic 
Distribution) 

2.  Change  the  message  types  which  can  be  accessed  by  a 
populated  staff  module  on  a  query  basis  (Query  Distri¬ 
bution) 

3.  Change  the  threshold  values  for  submission  of  event 
triggered  reports  (Reporting  Threshold) 

4.  Change  the  period  for  submission  of  periodic  reports 
(Reporting  Period) 

5.3.2  Availability  of  "Source  Identity" 

The  basic  control  parameter  for  this  category  is: 

5.  Selectively  delete  "source  identity"  from  spot  reports 
submitted  to  the  populated  G2  module  (Source  Identity) 

5.3.3  Time  Constraints  for  Decision  Making 

The  basic  control  parameters  for  this  category  are: 


6. 


Change  the  requirements  for  submission  of  "record" 
outputs,  i.e.,  outputs  that  are  not  entered  directly 
into  the  simulation,  from  a  populated  staff  module 
(Record  Requirement) 

Change  the  pace  of  the  simulated  combat  by  altering  the 
ratio  between  game  clock  time  and  wall  clock  time 
(Speed  Ratio) 


5.3.4  Quality  of  Information 


The  basic  control  parameters  for  this  category  are: 

8.  Change  the  delay  times  between  trigger  event  and 
message  receipt  (Message  Delay) 

9  Change  the  error  rate  in  message  generation  (Error 
Rate) 

10.  Change  the  rate  at  which  blank  or  random  alphanumerics 
are  introducted  into  messages  (Omission  Rate) 

5.3.5  Research  Applications 

The  ten  basic  control  parameters  enumerated  above  permit  a 
wide  range  of  research  subjects  to  be  investigated  by  means  of  the 
model.  A  small  number  of  these  is  indicated  in  Table  5-2  together 
with  the  pertinent  basic  control  parameters. 

5.3.6  Adaptive  Behavior 


The  discussion  of  control  parameters  to  this  point  has  been 
limited  to  the  study  of  manual  staff  performance,  i.e.,  without  ADP 
assistance.  Providing  ADP  assistance  opens  up  a  whole  new  vista  of 
staff  performance  study.  In  the  ADP  mode  it  becomes  feasible  to 
provide  the  player  himself  some  degree  of  control  over  the  form  in 
which  it  is  presented  --  normally  by  means  of  visual  displays.  Such 
an  adaptive  capability  can  be  provided  by  means  of  adaptive  software 
that  can  be  made  available  with  "smart  Terminals."  This  capability 
will  not  be  incorporated  in  the  intial  implementation  of  the  simula¬ 
tion,  but  can  be  added  later  as  additional  resources  become  available. 
A  major  advantage  of  AOP  staff  operation  from  the  point  of  view  of  the 
exp ermenter  is  that  so  much  of  the  internal  information  flow  within 
the  staff  module  now  appears  at  the  I/O  terminal  provided  the  player. 
Much  of  the  internal  instrumentation  that  had  to  be  superimposed  on 
the  manual  staff  is  now  inherent  in  the  terminal  which  can  record 
the  frequency  of  access  to  the  data  base  by  information  category, 
the  kinds  of  and  frequency  with  which  information  processes  are 
invoked,  and  the  forms  selected  by  the  player  for  information  display. 
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Section  6 


DESIGN  OF  THE  INITIAL  IMPLEMENTATION 
(LIVE  INTELLIGENCE  (G2)  MODULE) 

This  section  pulls  together  the  design  features  that  apply 
to  the  initial  implementation  of  the  simulation  in  the  configuration 
consisting  of  two  live  modules  (Blue  G2  vs  Red  Command  Module  -- 
Configuration  Number  36)  or  one  live  module  (Blue  G2  --  Configuration 
Number  4).  As  such  it  will  repeat  or  reference  materiel  already 
presented  elsewhere  in  the  report  in  the  more  general  context  of 
multiple  configurations. 

6.1  PHYSICAL  LAYOUT 

A  feasible  physical  layout  of  the  simulation  in  Configuration 
Number  36  is  shown  at  Figure  6-1,  which  is  a  repetition  of  the  layout 
shown  at  Figure  4-5.  At  the  left  of  the  figure  is  the  live  G2  module 
showing  stations  for  four  personnel  and  typical  equipment  (files, 
workbook,  journal,  displays)  for  operation  in  the  manual  mode.  The 
two  pieces  of  equipment  unique  to  the  simulation  are  the  teletype 
printer  (for  incoming  traffic  generated  by  the  Battle  Outcome  Gen¬ 
erator)  and  the  pass  through  window  for  incoming  traffic  generated 
outside  the  Battle  Outcome  Generator  and  for  all  outputs  of  the  G2 
staff  module  (orders,  queries,  responses,  and  requests).  The  center 
section  of  the  figure  shows  the  simulation  proper  with  the  computer 
at  the  top  and  the  human  controllers  in  the  lower  portion.  Physical 
equipment  in  the  controllers  section  consists  of  a  cathode  ray  ter¬ 
minal,  a  high  speed  printer,  and  a  Controller's  Situation  Map.  Shown 
at  the  right  is  the  live  Red  command  module.  It  also  contains  the 
two  simulation  unique  equipments,  the  teletype  printer  and  the  pass 
through  window. 

It  should  be  noted  that  the  initial  implementation  can  also 
be  played  in  Configuration  4  (live  G2  module  only).  In  this  case  the 
functions  of  the  Red  player  are  taken  over  by  the  Controller(s)  if  the 
experiment  objective  requires  interaction  on  the  part  of  the  Red  side 
i.e.,  that  Red  orders,  requests,  etc.  be  dependent  on  the  actual 
status  of  the  force  interactions  at  any  particular  time.  If  Red 
interaction  is  not  required,  the  outputs  from  the  Red  side  can  simply 
be  scheduled  and  treated  as  if  they  were  scenario  events. 

6.2  PERSONNEL  REQUIREMENTS 
6.2.1  Blue  G2  Module 

The  TOE  of  the  Armored  or  Mechanized  Infantry  Division  (TOE 
17-4H)  provides  a  G2  section  consisting  of  6  officers  and  9  enlisted 
men.  There  is,  however,  a  much  larger  group  within  the  division 


involved  in  both  intelligence  and  EW  activities,  much  of  it  at 
division  level.  This  is  the  Combat  Electronic  Warfare  Intelligence 
(CEWI)  battalion  whose  HQ  company  maintains  an  Electronic  Warfare 
Intelligence  Operations  Center  (EWIOC)  for  the  production  and  dis¬ 
semination  of  integrated  all-source  intelligence,  mission  management 
for  intelligence  and  electronic  warfare  operations  and  performance 
of  the  SSO  function.  As  such,  this  center  works  closely  with  both 
the  G2  and  G3  sections  of  the  division  general  staff.  It  is  profit¬ 
able  to  look  more  carefully  at  the  organization,  mission,  and  func¬ 
tions  of  the  CEWI  battalion  in  order  to  develop  a  rationale  for  how 
much  of  its  activities,  if  any,  should  be  included  in  the  G2  staff 
module,  quite  aside  from  the  pragmatic  consideration  that  the  G2 
module  could  easily  become  so  large  as  to  be  unmanageable  and  unafford¬ 
able.  The  following  is  an  extract  from  the  draft  document.  Training 
Text  30-115T,  COMBAT  ELECTRONIC  'WARFARE  INTELLIGENCE  BATTALION  (CEWI 
BN)  DIVISION,  prepared  by  the  US  Army  Intelligence  Center  and  School, 
Fort  Huachuca,  Arizona,  15  June  1976. 

"COMBAT  ELECTRONIC  WARFARE  INTELLIGENCE  BATTALION,  DIVISION 


"2-1.  ORGANIZATION.  TOE  30-115T  was  developed  in  response  to  the 
Chief  of  Staff's  decisions  to  integrate  intelligence  and  electronic 
warfare  assets  at  the  tactical  echelon.  Organic  to  this  battalion 
are  three  companies:  Headquarters  and  Operations  Company,  TOE  30- 
116T;  Electronic  Warfare  Company,  TOE  30-117T;  and  Ground  Surveil¬ 
lance  Company,  TOE  30-1 18T. 


Figure  1-1 


"2-2.  MISSION.  This  battalion,  organic  to  an  armored  or  infantry 
(mechanized)  division,  provides  combat  intelligence  and  electronic 
warfare  functions  in  support  of  the  division. 

"2-3.  FUNCTIONS.  The  CEWI  battalion  provides  integrated  intelligence 
analysis  and  production,  timely  intelligence  dissemination,  integrated 
mission  planning  and  management,  command  and  control,  centralized  log¬ 
istics  and  administrative  support  for  intelligence  assets,  and  intelli 
gence  skills  in  the  three  basis  disciplines:  HUMINT,  Imagery,  and 
Electromagnetic.  The  battalion  provides  electronic  warfare  planning, 
coordination  and  execution. 


T 
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a.  The  CEWI  Bn  supports  the  division  by  providing  electronic 
warfare  and  combat  intelligence  in  the  fields  of  signals  intelligence, 
imagery  interpretation,  interrogation  and  ground  surveillance.  The 
battalion,  through  the  Electronic  Warfare  Intelligence  Operations 
Center  ( EWI  Op  Ctr),  which  is  comprised  of  the  Mission  Management  and 
Dissemination  Section  (MMDS),  All-Source  Production  Section  (ASPS) 
and  the  Electronic  Warfare  Section  (EWS),  provides  electronic  warfare 
support  and  integrated  all -source  intelligence  to  the  commander.  In 
addition,  the  functions  of  counterintelligence  (Cl)  and  signals  sec¬ 
urity  (SIGSEC)  are  also  provided  by  elements  of  the  battalion.  A  US 
Air  Force  Weather  Section  (USAF  WX  SEC)  is  attached  to  the  battalion 
to  provide  weather  support  for  the  division. 

b.  The  CEWI  Bn  provides  a  single  intelligence  and  electronic 
warfare  commander  who  is  responsible  for  the  integrated  management  of 
all  assets  in  his  command.  He  is  responsible  for  the  execution  of 
intelligence  tasks,  to  include  analysis,  production,  dissemination, 
and  collection  planning,  and  for  the  execution  of  EW  mission  planning 
and  execution.  The  battalion  operates  under  the  general  staff  super¬ 
vision  of  the  G2,  and  responds  to  the  G2  in  matters  of  intelligence 
and  to  the  G3  in  matters  pertaining  to  EW.  The  commander  also  exer¬ 
cises  centralized  command,  control  and  supervision  of  the  administra¬ 
tive  and  logistical  support  functions  of  the  battalion. 

c.  The  battalion  provides  RATT/AM/SSB  communications  during 
initial  employment  of  the  battalion,  and  as  an  alternate,  FM/AM/SSB 
for  command  and  control.  Area  multichannel  communications  provided 
by  the  division  signal  battalion  are  used  to  the  maximum  extent 
possible  for  intelligence  operational  traffic. 

d.  This  organization  is  capable  of  providing  direct  support 
(DS)  maintenance  on  communications  and  electronic  equipment,  less 
RAD I AC,  and  general  maintenance  support  (GS)  on  electronic  warfare 
(EW)  equipment.  The  battalion  performs  organizational  maintenance 
on  all  other  items  of  equipment.  The  battalion  is  dependent  upon 
appropriate  elements  of  the  division  for  medical,  religious,  finan¬ 
cial,  legal,  and  personnel  administrative  services,  the  divisional 
signal  organization  for  service  into  the  area  communications  system, 
areas." 


From  the  above  extract,  it  is  clear  that  the  CEWI  battalion 
provides  a  formal  structure  for  two  separate  but  highly  integrated 
support  systems  for  the  division:  the  intelligence  support  system 
and  the  electronic  warfare  support  system.  Further,  the  intelligence 
system  is  under  staff  supervision  of  the  G2  and  the  EW  system  under 
the  supervision  of  the  G3.  Thus,  the  CEWI  battalion  provides  special 
staff  services  and  executes  operations  in  much  the  same  way  as  other 
specialized  support  organizations,  e.g.,  division  artillery,  the 
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engineer  battalion,  or  the  signal  battalion.  The  general  staff,  on 
the  other  hand,  assists  the  commander  in  carrying  out  what  have  been 
called  the  integrating  functions:  see,  plan,  allocate,  fight,  sus¬ 
tain,  and  communicate.  There  is,  thus,  a  philosophical  basis  for 
distinguishing  between  carrying  out  such  integrating  functions  and 
the  performance  of  specialized  support  functions  by  the  support  systems. 
This  distinction  is  made  clear  in  the  Combined  Arms  Combat  Development 
Agencies  (CACDA)  current  approach  to  the  Technical  Interface  Concept 
(TIC)  of  the  Corps  Battlefield.’ 

On  this  basis,  then,  there  is  no  more  reason  for  including 
elements  of  the  CEWI  battalion,  to  include  the  all  source  analysis 
and  the  EW  components  of  the  EWIOC,  in  the  general  staff  modules  than 
for  the  engineer  battalion  or  the  signal  battalion.  The  simulation 
will,  therefore,  threat  the  components  of  the  EWIOC  as  a  part  of  the 
battle  outcome  generator  and  not  as  a  component  of  either  the  G2  or 
G3  staff  modules.  The  activities  of  the  all-source  analysis  center 
will  be  included  iri  the  algorithms  which  generate  the  perceived  data 
base  from  the  real  data  base. 

Having  made  this  design  decision,  it  is  clear  that  no  simulated 
special  intelligence  will  appear  in  any  of  the  message  traffic  gen¬ 
erated  by  the  simulation  because  all  of  the  intelligence  produced  by 
the  EWIOC  and  flowing  to  G2  will  be  "sanitized"  so  as  not  to  disclose 
sources  of  special  intelligence.  This  needs  further  consideration  in 
view  of  Task  2b  of  the  contract  which  states  that,  "Explicit  consid¬ 
eration  shall  be  given . to  the  tradeoffs  involved  in  the 

inclusion  of  special  intelligence."  A  number  of  factors  apply  to 
such  consideration.  The  first  factor  is  that  current  policy  provides 
that  information  available  at  division  level  from  special  intelligence 
sources  of  higher  HQs  will  normally  be  sanitized  at  corps  level  (e.g., 

SI  from  national  sources)  so  that  such  SI  is  not  normally  available 
in  any  case  at  division  level.  SI  from  sources  within  the  division 
(CEWI  battalion)  is,  of  course,  available  within  the  EWIOC  and  would 
normally  be  accessible  to  the  commander,  the  G2  and  G3.  However, 
properly  processed  intelligence  will  indicate  the  level  of  uncertainty 
associated  with  a  given  report  --  a  level  assigned  on  the  basis  of 
known  performance  of  the  source.  It  will  be  assumed  that  the  simu¬ 
lated  all-source  analysis  processing  will  satisfactorily  assign  such 
uncertainties.  It  should  be  pointed  out,  however,  that  this  does  not 
preclude  consideration  of  "sources"  from  the  evaluation  of  G2  module 
performance  because  special  intelligence  is  not  the  only  component 
of  battlefield  intelligence.  The  G2  must  consider  dat  from  many 
other  sources  available  to  him,  e.g.,  the  reconnaissance  squadron, 
the  maneuver  units,  and  division  artillery,  to  name  but  a  few.  These, 
too,  must  be  evaluated  and  result  in  an  assignment  of  uncertainty 

Solicitation  Number  PAAK  21-79-R-9010,  study  entitled  "Technical 

Interface  Concept  (TIC)  on  the  Corps  Battlefield,"  Harry  Diamond 

Laboratories,  18  Dec  78. 
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based  on  known  performance  of  such  sources,  so  that  availability  of 
source  identity  remains  a  feasible  control  variable  for  62  evaluation. 

The  task  statement  cited  above  also  provides  that  explicit 
attention  be  given  to  the  play  of  EW  in  the  simulation.  It  is  per¬ 
tinent  to  examine  the  various  components  of  EW  as  illustrated  in 
Figure  6-2.  The  three  major  components  are  electronic  support  measures 
(ESM),  electronic  countermeasures  (ECM)  and  electronic  counter-counter 
measures  (ECCM).  As  indicated  in  the  figure  this  activity  is  under 
the  staff  supervision  of  the  G3  which,  in  the  simulation,  means  that 
staff  inputs  such  as  the  Enemy  Electronic  Order  of  Battle  (EEOB) 
flow  from  the  EWIOC  to  the  G3  staff  module  and  that  decision  outputs 
to  jam  appear  as  frag  orders  to  engage  in  jamming  from  the  G3  module. 
However,  as  shown  in  the  figure,  inputs  are  required  from  both  ESM 
and  ECM  in  order  to  make  decisions  as  to  whether  enemy  electronic 
emitter  should  be  exploited,  jammed,  or  destroyed.  Such  decisions 
involve  not  only  the  G3,  but  also  the  G2  and  the  FSE.  The  necessary 
intra-module  staff  coordination  for  such  decisions  is  provided  by 
means  of  the  "request"  procedures  described  in  Design  Note  G.  This 
procedure  provides  that  a  simulated  G3  module  would  provide  a  copy 
of  a  frag  order  directing  jamming  operations  to  the  G2  for  concurrence 
prior  to  submitting  it  to  the  BPG  for  implementation.  Similarly,  FSE 
would  coordinate  with  both  G3  and  G2  prior  to  issuing  a  frag  order  for 
destruction  of  an  electronic  target.  It  is  also  possible  for  a  live 
G2  module  to  write  a  frag  order  directing  jamming  operations  to  begin 
and  forward  it  to  G3  tor  implementation.  This  amounts  to  a  recommen¬ 
dation  to  initiate  jamming.  In  a  similar  vein,  the  simulation  will 
provide  that  a  simulated  G3  module  will,  on  receipt  of  the  EEOB  from 
the  EWIOC  provide  an  information  copy  to  the  live  G2.  Thus,  although 
EW  is  technically  under  the  purview  of  the  G3,  the  model  does  provide 
for  the  live  G2  to  participate  in  the  EW  decision  processes. 

Having  established  a  sound  basis  for  populating  the  G2  module 
only  with  TOE  personnel,  we  are  finally  able  to  address  the  question 
of  the  size  of  the  G2  module  personnel  complement.  Something  less 
than  half  of  the  authorized  personnel  strength  (6  officers,  9  enlisted 
men)  would  be  on  shift  at  any  one  time.  As  has  already  been  dis¬ 
cussed  in  paragraph  3.4.5,  providing  players  with  hard  copy  eliminates 
many  of  the  lower  level  communication  and  message  center  processes 
required  for  oral  communication,  thus  further  reducing  the  manpower 
requirements.  On  this  basis,  we  visualize  the  personnel  complement 
of  the  populated  G2  module  will  be  from  3-5  persons  depending  upon 
the  objectives  of  a  given  experiment. 
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Figure  6-2.  Components  of  EW. 


6.2.2  Control  Module 


As  has  already  been  stated  in  paragraph  4.2,  the  proposed 
initial  implementation  is  predicated  on  a  maximum  of  two  persons  in 
the  Control  module  to  direct  and  operate  the  system.  Although  some 
scenarios  could  probably  be  run  with  only  one  person  in  Control,  it 
is  considered  unlikely  that  very  many  experiments  involving  inter¬ 
action  between  a  live  G2  and  a  live  Red  command  module  could  be  run 
with  less  than  one  controller  maintaining  the  Controller's  SITMAP 
and  another  operating  the  machine  terminal. 

6.2.3  Red  Command  Module 

For  those  experiments  for  which  a  live  Red  command  module  is 
required,  this  module  will  need  one  player.  The  tactical  information 
messages  to  include  the  possible  outputs  from  and  the  simulation  in¬ 
puts  into  the  Red  Command  module- have  been  identified  at  Design  Note 
A  by  an  asterisk.  This  number  has  been  adjusted  so  that  the  decisions 
required  from  a  Red  player  should  be  within  the  capability  of  a  single 
player. 

6.3  OUTPUTS  AND  INPUTS 

The  specific  list  of  allowable  outputs  (Class  3  only)  of  a 
live  G2  module  and  the  list  of  possible  input  messages  (Class  4  only) 
to  such  a  model  is  shown  at  Table  6-1.  This  has  been  extracted  from 
Design  Note  A.  The  outputs  are  at  the  top  of  the  table  and  the  in¬ 
puts  at  the  bottom. 

The  permissible  list  of  modular  addressees  for  the  G2  staff 
module  outputs  is  shown  at  Table  6-2.  This  has  been  extracted  from 
Design  Note  B.  Which  of  these  permissible  addressees  will  in  fact 
receive  a  copy  of  a  selected  output  is  determined  by  the  players. 

Table  6-2  also  lists  only  Class  3  outputs. 

The  relation  between  inputs  and  outputs  of  the  live  G2  module 
is  shown  in  input/output  matrix  form  in  Table  6-3  which  had  been  ex¬ 
tracted  from  Design  Note  C.  This  lists  all  Class  2,  3,  and  4  events. 
Whether  this  relation  is  in  fact  observed  by  live  players  is,  of 
course,  a  matter  of  their  choice. 

6.4  CONTROL  PARAMETERS 

To  be  useful  for  human  factors  research  on  the  behavior  of 
decision  makers  within  the  populated  G2  module,  the  simulation  will 
provide  a  number  of  control  parameters  to  the  experimenter  that  can 
be  used  to  control  the  quality  and  quantity  of  the  information  avail¬ 
able  to  the  decision  maker.  These  have  already  been  discussed  in  a 
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Table  6-1.  Intelligence  Staff  Module. 


Table  6-2.  Module  Outputs  and  Their  Modular  Addresses. 
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Table  6-3.  Input/Output  Matrix  for  Intelligence  Staff 
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more  general  context  in  paragraph  5.3  but  are  repeated  here  for  the 
sake  of  completeness.  The  top-down  design  described  in  Section  4 
provides  the  following  control  parameters: 

6.4.1  Amount  and  Kind  of  Information 

The  basic  control  parameters  for  this  category  are: 

1.  Change  the  distribution  of  message  types  provided 
automatically  to  the  populated  62  staff  module 
(Automatic  Distribution) 

2.  Change  the  message  types  which  can  be  accessed  by 

a  populated  G2  staff  module  on  a  query  basis  (Query 
Distribution) 

3.  Change  the  threshold  values  for  submission  of  event 
triggered  reports  (Reporting  Threshold) 

4.  Change  the  period  for  submission  of  periodic  reports 
(Reporting  Period). 

6.4.2  Availability  of  "Source  Identity" 

The  basic  control  parameter  for  this  category  is: 

5.  Selectively  delete  "source  identity"  from  spot  reports 
submitted  to  the  populated  G2  module.  (Source  Identity) 

6.4.3  Time  Constraints  for  Decision  Making 

The  basic  control  parameters  for  this  category  are: 

6.  Change  the  requirements  for  submission  of  "record" 
outputs,  i.e.,  outputs  that  are  not  entered  directly 
into  the  simulation,  from  the  populated  G2  staff 
module  (Record  Requirement). 

7.  Change  the  pace  of  the  simulated  combat  by  altering 
the  ratio  between  game  clock  time  and  wall  clock 
time  (Speed  Ratio). 

6.4.4  Quality  of  Information 

The  basic  control  parameters  for  this  category  are: 

8.  Change  the  delay  times  between  trigger  event  and 
message  receipt  (Message  Delay). 
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9.  Change  the  error  rate  in  message  generation  (Error 
Rate). 

10.  Change  the  rate  at  which  blank  or  random  alphanumerics 
are  introduced  into  messages  (Omission  Rate). 

6.4.5  Research  Applications 

The  ten  basic  control  parameters  enumerated  above  permit  a 
wide  range  of  research  subjects  to  be  investigated  by  means  of  the 
model.  A  small  number  of  these  is  indicated  in  Table  6-4  together 
with  the  pertinent  basic  control  parameters. 

6.5  MEASUREMENTS  AND  EVALUATION 

The  previous  discussion  at  paragraph  5.2  is  equally  valid 
for  the  live  62  module  and  is  repeated  here  for  the  sake  of  com¬ 
pleteness.  Some  of  the  pertinent  considerations  affecting  live  staff 
performance  measurement  have  already  been  addressed  in  paragraph 
2.4.4.  There  it  was  pointed  out  that  measurements  within  the  infor¬ 
mation  network  are  limited  to  measurements  of  time  and  effort  asso¬ 
ciated  with  the  preparation  of  specified  staff  outputs  and  measure¬ 
ments  of  information  content  of  such  outputs  such  as  completeness, 
accuracy  and  validity  for  a  very  limited  portion.  It  was  further 
pointed  out  that  complete  measurements  of  the  quality  of  information 
content  cannot  be  made  entirely  within  the  information  system  but 
must  be  inferred  from  the  outcomes  of  the  combat  simulation.  Points 
between  which  certain  classes  of  measurement  can  be  made  were  also 
defined. 

In  view  of  the  modular  nature  of  this  simulation  and  the 
basic  concept  which  provides  that  every  information  transfer 
across  the  boundaries  of  a  staff  module  must  be  made  explicit,  the 
measurement  of  staff  performance  can  be  divided  into  measurements 
made  at  the  boundaries  of  live  staff  modules  and  measurements  within 
staff  modules.  Each  of  these  is  discussed  in  the  following  subpara¬ 
graphs. 

6.5.1  Measurements  Outside  the  Staff  Module 

The  top-down  design  outlined  in  Section  4  provides  for  the 
following  kinds  of  measurements  at  the  live  G2  module  boundary: 

•  Logging  the  time  of  entry  into  the  simulation  of 

every  62  staff  output.  This  includes  outputs  which 
are  entered  into  the  computer  and  those  outputs  which 
are  simply  recorded  and  filed. 
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•  Logging  the  time  of  delivery  of  every  staff  input 
provided  to  the  live  G2  players  whether  those  are 
generated  by  the  computer  or  delivered  by  the  controller 
from  the  file  of  previously  prepared  written  entries. 

•  Recording  the  content  of  every  G2  module  input  and 
output  whether  processed  by  the  computer  or  hand 
processed  by  Control. 

From  these  recorded  data  the  following  kinds  of  performance  measure¬ 
ments  can  readily  be  extracted: 

•  Time  delays  between  selected  inputs  and  outputs. 

•  Time  delays  between  selected  triggers  and  outputs. 

•  Completeness  of  selected  staff  outputs  with  respect 
to  inputs  provided. 

•  Accuracy  of  selected  staff  outputs  with  respect 
inputs  provided. 

•  Numbers  of  selected  outputs  generated. 

•  Numbers  of  selected  inputs  provided. 

•  Numbers  of  queries  generated  for  selected  classes  of 
information. 

Measurement  of  the  quality  of  the  content  of  G2  staff  module 
decisions,  as  evidenced  by  the  outputs,  must  be  made  in  terms  of 
their  effects  on  the  battle  outcome.  The  discussion  at  paragraph 
2.4.6  indicated  the  effectiveness  measures  that  can  be  used  to 
measure  the  relative  mission  accomplishment  of  alternative  solutions 
to  battlefield  management.  These  are: 

•  Changes  in  geographic  area  controlled  by  each  side. 

•  Changes  in  the  resources  consumed  and  available. 

•  Time  intervals  required  to  effect  above  changes. 

The  design  delineated  in  Section  4  provides  these  output  measures 
as  follows: 

•  Changes  in  geographic  area  are  available  as  unit 
locations  both  in  the  Real  Data  Base  and  on  the 
Controllers  SITMAP. 

•  Changes  in  resources  are  available  as  characteristics 
of  the  units  whose  status  is  maintained  in  the  Real 
Data  Base. 
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Measurements  Inside  the  G2  Staff  Module 


The  discussion  at  paragraph  5.2.2  covered  the  question  of 
performance  measurements  inside  the  staff  module  in  some  detail  and 
applies  equally  to  the  populated  G2  staff  module.  Because  of  its 
length  it  will  not  be  repeated  here. 

In  summary,  SAI's  consideration  of  possible  alternatives  to 
instrumentation  inside  the  live  G2  module  leads  us  to  the  following 
conclusions: 

•  The  collection  of  data  regarding  player  performance 

in  the  manned  staff  modules  can  be  accomplished  either 
on  a  time  increment  basis  or  through  event-oriented 
techniques.  At  this  time,  some  combination  of  both 
alternatives  seems  desirable. 

•  Subjective  techniques  (interviews,  questionnaires, 

group  discussions,  etc.)  may  be  useful  for  formula¬ 
ting  initial  concepts  as  to  staff  behavior,  but  must 
be  verified  or  modified  through  objective  experiment. 

6.6  PLAN  FOR  INITIAL  IMPLEMENTATION 

6.6.1  Major  Tasks  to  be  Accomplished 

1 .  Prepare  Model  Description 

Description  of  the  model  from  the  user's  point  of 
view.  Includes  description  of  the  capabilities  and 
limitations  of  the  prototype  version  (G2  live),  general 
information  flow,  macro-logic,  data  base  organization, 
required  and  feasible  pre-play  inputs,  general  operat¬ 
ing  procedures,  model  outputs,  instrumentation  of 
live  modules,  complete  listing  of  all  English  language 
formats. 

Level  of  Effort:  5  TMM 

2.  Prepare  Controller's  Manual 

Detailed  instructions  for  the  Controllers  to  include: 

•  Pre-loading  instructions,  to  include  terminal 
operation 

•  Operating  instructions,  to  include  terminal 
operation 

•  Terminating  and  re-start  instructions 


•  Special  instructions  for  Control  when  Red 
command  module  is  simulated. 

Level  of  Effort:  5  TMM 

Prepare  G2  Player's  Manual: 

Detailed  instructions  for  live  players  in  the  G2  module 
to  include: 

•  Permissible  decision  variables 

•  Detailed  division  staff  SOP 

•  English  language  input  and  output  formats 

Level  of  Effort:  5  TMM 
Prepare  Red  Player's  Manual 

Detailed  instructions  for  live  player  in  Red  Command 
module  to  include: 

•  Permissible  decision  variables 

•  Detailed  division  staff  SOP 

•  English  language  input  and  output  formats 

Level  of  Effort:  2  TMM 

Scenario  Preparation 

This  task  involves  the  following: 

•  General  instructions  on  preparation  of  a 
scenario  (preloading  of  model)  to  address 
typical  test  objectives 

•  Preparation  of  a  test  scenario  which  addresses 
a  specific  ARI  test  objective. 

Level  of  Effort:  5  TMM 

Develop  and  Test  the  ADP  Portion  of  the  Model 

This  task  covers  the  programming  and  testing  of  the 
ADP  software  required  to  load,  operate,  stop,  and 
re-start  the  model,  as  well  as  any  required  post¬ 
processing. 
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Model  Demonstration 


This  model  will  be  demonstrated  using  the  test  scenario 
in  two  phases: 

•  Initial  demonstration  of  SAI  facilities 

•  Final  demonstration  of  model  on  ARI  facilities 

Level  of  Effort:  10  TMM 

8.  Prepare  Technical  Documentation 

This  task  involves  preparation  of  the  complete  technical 
documentation  of  the  ADP  programs  developed  in  Task  6 
in  accordance  with  prescribed  standards. 

Level  of  Effort:  12  TMM 

Total  Estimated  Effort:  66  TMM 

Estimated  Computer  Costs:  $10,000.00 

6.6.2  Schedule  for  Completion  of  Initial  Implementation 

The  tasks  listed  above  would  be  completed  in  a  period  of  18-24 
months  after  initiation.  The  critical  path  that  determines  this  time 
length  involves  software  preparation  (Task  6}  and  the  demonstration 
of  the  completed  model  (Tasks  7  and  8).  The  schedule  for  implement¬ 
ing  the  initial  version  of  the  simulation  is  shown  at  Figure  6-3.  This 
figure  shows  the  completion  schedule  for  the  eight  tasks  enumerated 
above  in  Gantt  Chart  form.  Also  shown  are  the  major  milestones. 
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PROPOSED  SCHEDULE 


Figure  6-3.  Schedule  for  Initial  Implementation. 


DISTRIBUTION 
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I  DCSPER.  ATTN:  CPS/OCP  1 

I  fhe  Army  Lil»,  Pun tagon,  ATTN.  RSB  Chief  1 

1  The  Army  Lit).  Pentagon,  ATTN:  ANRAL  3 

1  Ofc,  Asst  Sect  of  the  Army  (R&D)  1 

I  Tech  Support  Ofc.  OJCS  1 

I  USASA.  Arlington,  ATTN:  IARD  T  1 

1  USA  Rsch  Ole,  Durham.  ATTN:  Life  Sciences  Dir  1 

2  USARIEM,  Natick,  ATTN:  SGRO  UE  CA  1 

I  USAT  rc.  I  l  Clayton.  A  I  IN.  Sill  CMC)  A  I 

I  USAIMA.  Ft  Bragg.  Al  FN:  A1SUCTD-OM  1 

1  USAIMA,  Ft  Bragg,  ATTN:  Marguat  Lib  1 

1  US  WAC  Ctr  &  Sch,  Ft  McClellan,  ATTN:  Lit)  1 

I  US  WAC  Ctr  &  Sch.  Ft  McClellan.  ATTN:  Tog  Dir  1 

1  USA  Quartermaster  Sch,  Ft  Lee,  ATTN:  ATSM-TE  1 

I  Intelligence  Material  Dev  Ofc,  EWL,  Ft  Holabird  1 

1  USA  SE  Signal  Sch  Ft  Gordon,  ATTN:  ATSO-EA  1 

1  USA  Chaplain  Co  &  Sch.  F  i  Hamilton,  ATTN:  ATSC-TF  RD  1 

1  USATSCH,  F»  Eustis,  ATTN.  Edoc  Advisor  1 

1  USA  War  College.  Carlisle  Bar racks,  ATTN:  Lib  1 

2  WRAI R,  Neuiopsyrhi.itiy  Oiv  2 

t  DU.  SDA.  Mnnterey  1 

1  USA  Concept  Anal  Agcy.  Bethesda,  ATTN:  MOCA  MR  1 

t  USA  Concept  Anal  Agcy,  Bethesda,  ATTN:  MOCA  JF  1 

I  USA  Arctic  Test  Ctr.  APO  Seattle,  ATTN:  STEAC  Pl.-MI  1 

1  USA  Arctic  Test  Ctr.  APO  Seattle,  ATTN:  AMSTE-PL  TS  1 

1  USA  Armament  Cmd.  Redstone  Arsenal,  ATTN:  ATSK-TEM  1 

1  USA  Armament  Cmd.  Rock  Island.  ATTN:  AMSAR  TDC  1 

t  FAA-NAFEC,  Atlantic  City,  ATTN:  Library  1 

1  FAA  NApEC,  Atlantic  City,  ATTN:  Human  Engr  Br  1 

!  FAA  Aeronautical  Ctr,  Oklahoma  City,  ATTN:  AAC  44D  2 

2  USA  Fid  Arty  Sch.  Ft  Sill,  ATTN:  Library  2 

1  USA  Armor  Sch,  Ft  Knox,  ATTN:  Library  1 

1  USA  Armor  Sch.  Ft  Knox,  ATTN:  ATSB-DI  -F  1 

I  USA  Armor  Sch.  f  t  Knox.  ATTN  ATSB  DT  TP  1 

I  USA  Armor  Sch,  Ft  Knox,  ATTN  ATSB  CD  AD  I 


HQUSACDEC,  Ft  Ord.  ATTN:  Library 

HQUSACOEC,  Ft  Ord.  ATTN:  ATEC-  EX-E  Hum  Factors 

USAEEC,  Ft  Benjamin  Harrison.  ATTN:  Lilwmy 

USAPACDC,  Ft  Benjamin  Harrison,  ATTN.  ATCP  HR 

USA  Comm- Elect  Sch,  Fl  Monmouth,  ATTN:  ATSN  -  EA 

USAEC,  Ft  Monmouth.  ATTN:  AMSEL  CT  HOP 

USAEC,  Ft  Monmouth,  ATTN:  AMSEL -PA  P 

USAEC,  Ft  Monmouth,  ATTN:  AMSEL  Sl-CB 

USAEC,  Ft  Monmouth,  ATTN.  C,  Facl  Dev  8r 

USA  Materials  Sys  Anal  Agcy,  Aberdeen,  ATTN:  AMXSY  -P 

Edge  wood  Arsenal,  Aberdeen.  ATTN:  S  ARE  A  BL  H 

USA  Ord  Ctr  &  Sch,  Aberdeen,  ATTN:  ATSL-TEM-C 

USA  Hum  Engr  Lab,  Aberdeen,  ATTN:  Library/Oir 

USA  Combat  Arms  Tng  Bd,  Ft  Benning,  ATTN;  Ad  Supervisor 

USA  Infantry  Hum  Rsch  Unit,  Ft  Benning,  ATTN:  Chief 

USA  Infantry  Bd,  Ft  Benning,  ATTN:  STEBC  TE-  T 

USASMA.  Ft  Bliss.  ATTN:  ATSS  LRC 

USA  Air  Def  Sch,  Ft  Bliss.  ATTN:  ATSA  CTD  ME 

USA  Air  Def  Sch,  Ft  Bliss,  ATTN:  Tech  Lib 

USA  Air  Del  Bd.  Ft  Bliss,  ATTN:  FILES 

USA  Air  Def  Bd.  Ft  Bliss.  ATTN:  STEBD-PO 

USA  Cmd  &  General  Stf  College,  Ft  Leavenworth,  ATTN:  Lth 

USA  Cmd  &  General  Stf  College,  Ft  Leavenworth,  ATTN:  ATSW-SE  -  L 

USA  Cmd  &  General  Stf  College,  Ft  Leavenworth,  ATTN;  Erf  Advisor 

USA  Combined  Arms  Cmbt  Dev  Act.  Ft  Leavenworth,  ATTN:  DepCdr 

USA  Combined  Arms  Cmbt  Dev  Act,  Ft  Leavenworth.  ATTN:  CCS 

USA  Combined  Arms  Cmbt  Dev  Act.  Ft  Leavenworth,  ATTN:  ATCASA 

USA  Combined  Arms  Cmbt  Dev  Act.  Ft  Leavenworth,  ATTN:  ATCACO-E 

USA  Combined  Arms  Cmbt  Dev  Act,  Ft  Leavenworth.  ATTN:  ATCACC.-CI 

USAFCOM,  Night  Vision  Lab.  Ft  Belvoir,  ATTN:  AMSEL-NV-SD 

USA  Computer  Sys  Cmd,  Ft  Belvoir,  ATTN:  Tech  Library 

USAMERDC.  Ft  Belvoir,  ATTN:  STSFB  DQ 

USA  Eng  Sch,  Ft  Belvoir,  ATTN:  Library 

USA  Topographic  Lab.  Ft  Belvoir,  ATTN:  ETL  TD-S 

USA  Topographic  Lab.  Ft  Belvoir,  ATTN:  STINFO  Center 

USA  Topographic  Lab.  Ft  Belvoir.  ATTN:  ETL  GSL 

USA  Infi'Higi-no  Or  ft  Sch.  F{  Hii.ichur.i,  ATTN:  CTD  MS 

USA  Intelligence  Ctr  A  Sch,  Ft  Huachuca,  ATTN:  ATS-CTD— MS 

USA  Intelligence  Ctr  &  Sch,  Ft  Huachuca.  ATTN.  ATSI-TE 

USA  Intelligence  Ctr  &  Sch.  Ft  Huachuca,  ATTN:  ATSI-  TEX--GS 

USA  Intelligence  Ctr  &  Sch,  Ft  Huachuca,  ATTN:  ATSI-CTS-OR 

USA  Intelligence  Ctr  &  Sch,  Ft  Huachuca.  ATTN:  ATSI -CTD-  DT 

USA  Intelligence  Ctr  &  Sch,  Ft  Huachuca,  ATTN:  ATSI  -  CTO— CS 

USA  Intelligence  Ctr  &  Sch,  Ft  Huachuca,  ATTN:  DAS/SRD 

USA  Intelligence  Ctr  8r  Sch,  Ft  Huachuca,  ATTN:  ATSI— TEM 

USA  Intelligence  Ctr  A  Sch,  Ft  Huachuca,  ATTN:  Library 

CDR,  HQ  Ft  Huachuca.  ATTN:  Tech  Ret  Div 

CDR,  USA  Electronic  Prvg  Grd,  ATTN:  STEFP  MT-S 

HQ,  TCATA,  ATTN:  Tech  Library 

HQ,  TCATA,  ATTN:  AT  CAT-OP-Q.  Ft  Hood 

USA  Recruiting  Cmd,  Ft  Sheridan.  ATTN:  USARCPM-P 

Senior  Army  Adv..  USAFAGOD/TAC,  Elgin  AF  Aux  Fid  No.  9 

HQ.  US  ARP  AC.  DCSPER.  APO  SF  96558.  ATTN:  GPPE  SE 

Stimson  Lib,  Academy  of  Health  Sciences.  Ft  Sam  Houston 

Marine  Corps  Inst..  ATTN:  Dean-MCI 

HQ,  USMC,  Commandant,  ATTN:  Code  MTMT 

HQ,  USMC,  Commandant,  ATTN:  Code  MPI-20-28 

USCG  Academy.  New  London,  ATTN:  Admission 

USCG  Academy,  New  London,  ATTN:  Library 

USCG  Training  Ctr.  NY,  ATTN:  CO 

USCG  Training  Ctr,  NY,  ATTN:  Educ  Svc  Ofc 

USCG.  Psychol  Res  Bi,  DC.  ATTN  GP  1/62 

HO  Mid-Range  Br,  MC  Det,  Quantico,  ATTN:  P&S  Oiv 
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1  US  Marine  Corps  Liaison  Ofc,  AMC,  Alexandria,  ATTN  AMCGS-r 
1  USATRAOOC.  Ft  Monroe.  ATTN:  ATRO-ED 
6  USATRAOOC.  Ft  Monroe.  ATTN  ATPR  AD 
1  USATRAOOC.  Ft  Monroe.  ATTN:  ATTS-EA 

1  USA  Forces  Cmd.  Ft  McPherson,  ATTN:  Library 

2  USA  Aviation  Test  Bd,  Ft  Rucker.  ATTN:  STEBG-PO 

I  USA  Agcy  tor  Aviation  Safety,  Ft  Rucker.  ATTN:  Library 
I  USA  Agcy  for  Aviation  Safety,  Ft  Rucker,  ATTN:  Educ  Advisor 

1  USA  Aviation  Scb,  Ft  Rucker,  ATTN:  PO  Drawer  O 

t  HQUSA  Aviation  Sys  Cmd.  St  Louis.  ATTN:  AMSAV-ZDR 

2  USA  Aviation  Sys  Test  Act..  Edwards  AFB.  ATTN:  SAVTE-T 
I  USA  Air  Oef  Sch.  Ft  Bliss.  ATTN:  ATSA  TFM 

I  USA  Air  Mnl Hliiy  Rsch  ft  Dev  Lab,  Moffett  Fid,  ATTN:  SAVDL  AS 
1  USA  Aviation  Sch,  Res  Tng  Mgt.  Ft  Rucker,  ATTN:  ATST-T— RTM 
t  USA  Aviation  Sch.  CO.  Ft  Rucker,  ATTN:  ATST-O-A 
1  HQ.  OARCOM.  Alexandria.  ATTN:  AMXCD -TL 
1  HQ.  DARCOM.  Alexandria.  ATTN:  CDR 
1  US  Military  Academy,  West  Point,  ATTN:  Serials  Unit 
1  US  Military  Academy.  West  Point,  ATTN:  Ofc  of  Milt  Ldrshp 
1  US  Miiitaiy  Academy.  West  Point,  ATTN:  MAOR 
1  USA  Standardization  Gp.  UK,  FPO  NY,  ATTN:  MASE-GC 
1  Ofc  of  Naval  Rsch.  Arlington,  ATTN:  Code  452 

3  Ofc  of  Naval  Rsch,  Arlington,  ATTN.  Code  45B 
t  Ofc  of  Naval  Rsch,  Arlington.  ATTN  .  Code  450 
1  Ofc  of  Naval  Rsch.  Arlington.  ATTN.  Code  441 

1  Naval  Aerospc  Med  Res  Lah.  Pensacola.  ATTN;  Acous  Sch  Div 
I  Naval  Aerosix-  Med  Res  Lab.  Pensacola,  ATTN:  Code  L61 
I  Naval  Aerospc  Med  Res  Lab,  Pensacola,  ATTN:  Code  L5 
I  Chief  of  NavPers.  ATTN:  Pers  OR 
1  NAVAIRSTA.  Norfolk.  ATTN.  Safety  Ctr 
1  Nav  Oceanographic.  DC.  ATTN:  Code  6251.  Charts  ft  Tech 
1  Center  of  Naval  Anal.  ATTN:  Doc  Ctr 
1  NavAirSysCom,  ATTN  AIR-  531 3C 
1  Nav  BuMed.  ATTN:  713 
1  NevHelfcopterSut  ~>gua  2.  FPO  SF  96601 
1  AFMRL  (FT)  Williams  AFB 
1  AFHRL  (TT)  Lowry  AFB 

1  AFHRL  (AS)  WPAFB,  OH 

2  AFHRL  (DOJZ)  Brooks  AFB 

I  AFHRL  (DOJN)  Lackland  AFB 
1  HQUSAF  (INYSD) 

1  HQUSAF  (DPXXA) 

1  AFVTG  IRD)  Randolph  AFB 

3  AMRLIHE)  WPAFB.  OH 

2  AF  Inst  of  Tech.  WPAFB,  OH,  ATTN.  ENE/SL 
1  ATC  (XPTD)  Randolph  AFB 

1  USAF  AeroMed  L.b.  Brooks  AFB  (SUL  4).  ATTN:  OOC  SEC 
I  AFOSR  (NL),  Arlington 

I  AF  Log  Cmd.  McClellan  AFB.  ATTN  ALC/DPCRB 

1  Air  Force  Academy,  CO.  ATTN:  Dept  of  Bel  Sen 
5  NavPers  ft  Dev  Ctr.  San  Diego 

2  Navy  Med  Neuropsychiatric  Rsch  Unit.  San  D>ego 
1  Nav  Electronic  Lab.  San  Diego.  ATTN:  Res  Lab 

1  Nav  TrngCen.  San  Diego.  ATTN:  Code  9000-  Lib 
1  NavPostGraSch.  Monterey.  ATTN:  Code  55Aa 
1  NavPostGraSch,  Monterey.  ATTN:  Code  2124 
1  NavTrngEquipCtr,  Orlando,  ATTN-  Tech  Lib 
1  US  Dept  of  Labor.  DC.  ATTN:  Manpower  Admin 
I  US  Dept  of  Justice,  OC,  ATTN:  Drug  Enforce  Admin 
I  Nat  Bor  of  Standards,  DC.  ATTN:  Computer  Info  Section 
1  Nat  Clearing  House  for  MH-  Info,  Rockville 
1  Denver  Federal  Ctr.  Lakewood,  ATTN:  BLM 
12  Defense  Documentation  Canter 

4  Do  Psych.  Army  Hq.  Russell  Ofcs.  Canberra 

1  Scientific  Advsr,  Mil  Bd,  Army  Hq,  Russell  Ofcs,  Canberra 
1  Mil  and  Air  Attache,  Austrian  Embassy 

1  Centie  de  Recherche  Des  Facteurs,  Humaine  de  fa  Defense 
Nationals,  Brussels 

2  Canadian  Joint  Stall  Washington 

1  C/Air  Staff.  Royal  Canadian  AF,  ATTN  Pers  Std  Anal  Br 

3  Chief.  Canadian  Del  Rsch  Staff.  ATTN:  C/CRDSIW) 

4  British  Oef  Staff.  British  Embassy,  Washington 


1  Def  ft  Civil  Inst  of  Enviro  Medicine,  Canada 
1  AIR  CRESS.  Kensington.  ATTN:  Info  Sys  Br 
1  Mditaerpsykoloflisk  Tjeoeste,  Copenhagen 
1  Military  Attache,  French  Embassy.  ATTN:  Doc  Sec 
1  Medecin  Chef,  C.E.R.P  A. -Arsenal,  Toulon/Naval  France 
1  Prin  Scientific  Off,  Appl  Hum  Engr  Rsch  Oiv,  Ministry 
of  Defense.  New  Delhi 

1  Pers  Rsch  Ofc  Library,  AKA,  Israel  Defense  Forces 
1  Minister!*  van  Def e otic,  OOOP/KL  Afd  Sociaal 
Psychotogische  Zaken,  The  Hague,  Netherlands 


6-22 


